P201447

Nii3

A
AGARD-AG-183

oo

<

6
<*

<\

<

AGARDograph N o . 183 on

Principles of Avionics Computer Systems

Edited by J.N.Bloom

NORTH ATLANTIC TREATY

ORGANIZATION

DISTRIBUTION A N D AVAILABILITY O N BACK COVER

AGARD-AG-183

NORTH ATLANTIC TREATY ORGANIZATION ADVISORY GROUP FOR AEROSPACE RESEARCH AND DEVELOPMENT (ORGANISATION DU TRAITE DE L'ATLANTIQUE NORD)

AGARDograph No. 183 PRINCIPLES OF AVIONICS COMPUTER SYSTEMS Edited by J.N.Bloom Communications Research Centre Communications Canada

This AGARDograph has been prepared at the request of the Avionics Panel of AGARD.

THE MISSION OF AGARD

The mission of AGARD is to bring together the leading personalities of the NATO nations in the fields of science and technology relating to aerospace for the following purposes: Exchanging of scientific and technical information; Continuously stimulating advances in the aerospace sciences relevant to strengthening the common defence posture; Improving the co-operation among member nations in aerospace research and development; Providing scientific and technical advice and assistance to the North Atlantic Military Committee in the field of aerospace research and development; Rendering scientific and technical assistance, as requested, to other NATO bodies and to member nations in connection with research and development problems in the aerospace field; Providing assistance to member nations for the purpose of increasing their scientific and technical potential; Recommending effective ways for the member nations to use their research and development capabilities for the common benefit of the NATO community. The highest authority within AGARD is the National Delegates Board consisting of officially appointed senior representatives from each member nation. The mission of AGARD is carried out through the Panels which are composed of experts appointed by the National Delegates, the Consultant and Exchange Program and the Aerospace Applications Studies Program. The results of AGARD work are reported to the member nations and the NATO Authorities through the AGARD series of publications of which this is one. Participation in AGARD activities is by invitation only and is normally limited to citizens of the NATO nations.

Published December 1974 Copyright AGARD 1974 681.32:629.73.05

*
Set and printed by Technical Editing and Reproduction Ltd Harford House, 7 - 9 Charlotte St. London. WIP IHD

LIST OF CONTRIBUTORS

Chapter 1

INTRODUCTION J.N.Bloom Communications Research Centre Communications Canada BASIC DIGITAL COMPUTER CONCEPTS Prof. A.R.Meo Instituto di Elletrotecnica Generale, Politecnico di Torino, Italy DATA ACQUISITION AND COMMUNICATION FUNCTION Yngvar Lundh Norwegian Defence Research Establishment OPTIMISATION Yngvar Lundh SYSTEMS AND SYSTEMS DESIGN Dr C.S.E.Phillips Royal Radar Establishment, U.K. AVIONICS SYSTEM ARCHITECTURE R. E.Wright C.E. Digital Systems Development, Ferranti Ltd., Bracknell, U.K. DEFINING THE PROBLEM AND SPECIFYING THE REQUIREMENT Silvio Boesso and Rodolfo Gamberale, SELENIA, Industrie Elettroniche Associate SpA, Rome, Italy, MONITORING AND CONTROL OF AEROSPACE VEHICLE PROPULSION E.S.Eccles Smiths Industries Ltd., Aviation Division, U.K. MAN-MACHINE INTERFACE Dr E. Keonjian Engineering Consultant, U.S.A.

Chapter 2

Chapter 3

Chapter 4 Chapter 5

Chapter 6

Chapter 7

Chapter 8

Chapter 9

Chapter 10 NOVEL DEVICES AND TECHNIQUES Dr E.Keonjian and Dr A.L.Freedman Chapter 11 SPECIFYING THE REQUIREMENTS Dr A.L.Freedman The Plessey Company Ltd., U.K.

Edited by J.N.Bloom

iii

CONTENTS Page 1. INTRODUCTION 1.1 Purpose of the book 1.2 Plan of the book

1 1

2. BASIC DIGITAL COMPUTER CONCEPTS 2.1 The Functional Units of a Computer 2.2 Flip-Flops and Registers 2.3 Numeric Information coding in a Computer 2.4 Boolean Algebra 2.5 Building Blocks 2.6 The Arithmetic Unit 2.7 The Memory 2.8 The Control Unit 2.9 Input-Output Devices 2.10 Software 3. DATA ACQUISITION AND COMMUNICATION FUNCTION 3.1 Typical Devices to which an Avionics Computer is Connected 3.2 Data Types, Forms and Formats 3.3 Characteristics of Data 3.4 A/D and D/A conversion 3.5 Computer Interfacing 3.6 Data Transmission 3.7 The Programmer's View OPTIMISATION 4.1 The Optimisation Problem 4.2 Important Parameters 4.3 Typical Trade-Off Situations 4.4 Methods of Determining Adequacy

3 4 S 10 14 20 21 23 26 27

30 30 31 32 36 38 41

4.

42 43 44 46

5. SYSTEMS AND SYSTEMS DESIGN 5.1 Introduction 5.2 Systems 5.3 System Design Methodology 5.4 Programs as Systems 5.5 Functional System Approach 5.6 Purpose of Programming Network Diagrams 5.7 Data Rectangles 5.8 Process Circles 5.9 Example of a Simple Hierarchic Program Network 5.10 Hierarchy of Diagrams 5.11 Simulation and Testing 5.12 Real Time Computer Systems 5.13 Hierarchical Viewpoint 6. AVIONICS SYSTEM ARCHITECTURE 6.1 Introduction 6.2 The Practical Approach 6.3 Methods of Assessment of Computing Power and Information Rates 6.4 General Philosophies and Trade-Offs 6.5 Reliability Considerations 6.6 Examples of Avionic System Architecture 7. DEFINING THE PROBLEM AND SPECIFYING THE REQUIREMENT 7.1 Introduction 7.2 Survey of Typical Tasks of an Avionic System 7.3 From Operational Requirements to System Functions 7.4 From System Function to Computer Requirements 7.4.1 Presentation of the Requirements 7.4.2 An Example Set of Elementary Operations 7.4.3 Functional Analysis

47 47 48 49 51 52 52 55 56 56 61 61 62

64 66 71 73 78 82

88 88 89 92 92 93 99

IV

Page 7.4.4 7.4.5 7.4.6 7.4.7 7.4.8 7.4.9 7.4.10 7.4.11 Translation of the Model Mission Statistics Memory for Data Input-Output Execution Times and Instruction Set Instruction Word-Length and Format Memory for Program Total Memory Requirements

103 105 108 110 111 114 117 117

8. MONITORING AND CONTROL OF AEROSPACE VEHICLE PROPULSION 8.1 Introduction 8.2 Statement of the Problem 8.3 The Requirements of Propulsion Control and Monitoring 8.4 Definition of Design Failure Characteristics 8.5 System Selection and Architecture 8.6 System Architecture 8.7 Monitoring in Digital Computer Systems 8.8 Date Acquisition, Communication and Processing 8.9 Man-Machine Interface 8.10 Practical Realization 8.11 Conclusion 9. MAN-MACHINE INTERFACE 9.1 Introduction 9.2 Human Capabilities and Limitatioas of the Crew 9.3 Allocation of Functions to Man and Machine 9.4 Establishing Requirements for Information Display and Manual and Automatic Controls 9.5 Design of the Man-Machine Interface 9.6 Equipment for Man-Machine Interface 10. NOVEL DEVICES AND TECHNIQUES 10.1 Introduction 10.2 Large Scale Integration (LSI) Technology 10.3 Semiconductor and Other Types of Memories 10.4 Large Scale Integration (LSI) Testing 10.5 Functional Testing 10.6 Parametric Testing, D.C. and A.C. 10.7 Opto-Electronic Devices 11. SPECIFYING THE REQUREMENTS 11.1 Practical Definition of a System 11.2 Deriving the Specification of the System as a Whole 11.3 System Design 11.4 Devices and Techniques, An Overview

119 119 121 125 126 132 135 136 138 139 142

143 143 143 144 144 145

150 150 154 158 158 160 160

163 163 168 177

CHAPTER 1 INTRODUCTION J.N.Bloom 1.1 PURPOSE OF THE BOOK Modern computer systems comprise a set of structures that continue to grow in complexity, size and diversity. To the uninitiated, the amount of information available that describes these structures appears overwhelming. Often, career officers or civilian administrators with little or no computer systems background or experience find themselves in a position where they are charged with a sole or joint responsibility for the acquisition of a computer system. The purpose of this book is to provide these officers and administrators of the NATO countries with a package of information that will give them an understanding of the procedures involved in defining a requirement, specifying that requirement and, hopefully, of the convergent process that results in the satisfying of that requirement for a computer based system. This book presents to officials of the NATO countries an introductory treatment of the principles underlying the computer systems encountered in avionics, and provides an insight into the structural organization of those systems. The book explains the methodology behind the specification, analysis, design and implementation of computer based systems. The treatment of the material emphasizes avionic systems, but the principles are relevant and applicable to all computer systems. A systematic treatment in depth of all levels of computer organization is not possible in a book such as this. While sufficient material has been included in the text to achieve the principal goal of the book, that it be educational, extensive references will enable the interested reader to pursue certain topics of his or her special interest. 1.2 PLAN OF THE BOOK The organization of the material in the book is such that the fundamentals of computers and basic concepts are introduced in the early chapters. Gradually, the reader is introduced to the language of computer technology and the vocabulary of systems terminology. The basic chapter of this book is Chapter 2. The chapter serves as an introduction to the subject for those readers coming to it for the first time, as well as a useful review for those who have been exposed to it in the past. The next chapter, Chapter 3, introduces the reader to the problems of communicating with a machine, with the preparation and formatting of input data. The task faced by the programmer in assembling a list of instructions that will cause the computer to carry out a desired function is carefully described. Chapter 4, on optimization, discusses the important topic of definition of the problem for which solution the system is being assembled or acquired. The reader is shown that reality dictates a set of choices amongst alternatives; there are no ideal optimal solutions. The very complex subject of systems and system design is treated in Chapter 5. Fundamental ideas are introduced and used to develop a basis for the next level of concepts. The goal is to give the reader an insight into current concepts in design philosophy and methodology in systems. Chapter 6 on Avionics System Architecture provides the reader with a logical approach to the problem of determining the size of system required. The trade-offs and compromises that must be considered in arriving at a suitable system configuration are presented so that the reader can appreciate the problems posed by choosing from sets of alternatives. Some examples of typical systems are given to illustrate the ideas embodied in the text. Chapter 7 is a comprehensive chapter on a higher level than the preceding material. The fundamental ideas are introduced anew here, and brought to the point where the analysis of a typical, complex problem is undertaken.

The chapter develops more rapidly than the preceding ones, and is recommended for those readers with some background in computing machines. Chapter 8 illustrates how the material of the preceding chapters may be used. The chapter analyzes the problem of the monitoring and control of aerospace vehicle propulsion. The reader can trace the application of the principles introduced and discussed in the earlier chapters. A problem area introduced in preceding chapters is enlarged on in Chapter 9. The problem of the man-machine interface is of paramount importance and receiving a lot of attention from workers all over the world: but an exhaustive treatment of the man-machine interface is not possible in a book of this kind. Rather, some basic notions are introduced and the reader is left to follow up his interest by further reading. Chapter 10, too, is only of an introductory nature. Sufficient information is given to show the many aspects of semi-conductor technology today, and to indicate the variety of devices that contend for the designers attention when implementing a system. Chapter 11 is synoptic in nature, giving an overview of the book with some insight into the relationship of the parts. The great experience and insight that the author has into the problems of specifying computer systems requirements is evident; the reader will at once become familiar with some of the do's and don'ts of system acquisition.

CHAPTER 2 BASIC DIGITAL COMPUTER CONCEPTS A.R.Mao 2.1 THE FUNCTIONAL UNITS OF A COMPUTER A digital computer is usually viewed as consisting of five functional units: arithmetic unit, memory, control unit, input devices and output devices. The block diagram of such an organization is shown in Figure 2.1.

I *

ARITHMETIC UNIT
i

INPUT DEVICES
A

MEMORY
w

OUTPUT DEVICES
ii

1
l 1

4
i

_3 r

1 1
_ _ _ _ .

CONTROL UNIT

- TRUE INFORMATION COMMAND SIGNAL

Fig.2.1 The functional units of a computer

The arithmetic unit is the device where information is processed, that is, the arithmetical and logical operations involved in a given program are performed. The memory is the set of devices where is stored information currently not in use. Stored information includes: the numerical data to be processed; the sequence of the operations to be performed on the numerical data or program; the intermediate results; the final results to be delivered to the output. What is essential for an information processing system to be considered a computer, or, more accurately, a stored-program computer, is that memory should contain not only the problem data but also the program. Thus, for example, a desk calculator, which is functionally equivalent to the arithmetic unit alone, is not considered a computer. If the numerical data and the program can be as easily changed in the memory, the system is called a general-purpose computer, since it is hardly limited in the number of applications of any given type for which it can be used. In many airborne computers changing the content of the program memory implies a "rewiring of the machine", which is a relatively

complex operation. This drawback can be accepted when the system is designed for solving a specific class of problems, and in this case the system is referred to as a special-purpose computer. The input and output devices perform the functions of receiving and delivering the incoming and outgoing information, respectively. The control unit issues command and control signals to the remaining functional units of the system. It receives information pertaining to the program from the memory and assigns tasks, one at a time, to the other units. 2.2 FLIP-FLOPS AND REGISTERS Flip-flops Engineering considerations based on the analysis of cost, reliability and dimension have led to the conclusion that the best hardware atom is the bistable device, or flip-flop. The symbol for the flip-flop is shown in Figure 2.2.

1 OUTPUT ik.

0 OUTPUT il

Fig.2.2

The flip-flop

At present, a flip-flop consists of a pair of active elements (e.g., transistors) working reciprocally. When one of them passes current, the other is open; and vice versa. This implies that a flip-flop has states, arbitrarily labelled 0 and 1. The information pertaining to the state of the flip-flop is delivered to the output by means of the lines 0 output and 1 output. When the system is in the 0 state, the 0 output line is excited and the 1 output line is not excited. The contrary occurs when the system is in the 1 state. Three lines enter the block of Figure 2.2 one of them being often missing. A signal on the line labelled R (reset) sets the device to its 0 state, regardless of its present state. A signal on the line labelled S (set) sets the system to its 1 state, regardless of its present state. A signal on the line labelled C (complementation) changes the state of the system. A flip-flop can be set or reset in a few nanoseconds or tens depending on the type of logic used. Its content can be read as fast as a signal can scan the output. In principal, a flip-flop is a memory element; indeed, it is the smallest memory element, since it holds the information expressed by one binary digit, or bit. However, since its cost is relatively high, it is seldom used as an elementary unit of the true memory of a computer. Usually, flip-flops are introduced into all the functional units of a computer, especially the authmetic unit, as temporary, fast-access storage devices. Registers A register is an ordered set of flip-flops (or any other one-bit storage devices). Therefore, the content of a register is an ordered set of binary digits, or bits, which can be interpreted as a binary number. This ordered set of bits is often called a "word".

Figure 2.3 shows the symbol for the parallel register, namely, the one in which all the bits are set in parallel. Notice the double lines indicating the several signal lines transmit information into, or out of, the register, and the single line indicating the command signal on receipt of which the new word is introduced into the register.

INPUT INFORMATION

VL
COMMAND

V
OUTPUT INFORMATION
Fig.2.3 The symbol for the parallel register

The serial register is a register, that can receive and transmit only a single bit of information at a time. For example, the new bit is received at the left end and the output bit is delivered at the right end. The symbol for the serial register is shown in Figure 2.4 where the single line labelled "shift" indicates the command signal on receipt of which a new bit is received (and a new bit is delivered at the output).

OUTPUT INFORMATION

. INPUT INFORMATION

Fig.2.4

The symbol for the serial register

A particular type of serial register is the shift-register. On receipt of a command signal, a new bit is received at one end and the information content of any component flip-flop is transmitted one step toward the other end. However, the information content of the whole register can be read in parallel. 2.3 NUMERIC INFORMATION CODING IN A COMPUTER Because of the binary nature of the registers and the other building blocks, a computer is commonly built to handle ordered sets of binary digits. Such ordered sets can represent numbers or, more in general, combined alphabetic and numeric information, according to certain assumed codes. In this section, we shall briefly present a widespread way of representing binary numbers and performing arithmetical operations. Binary Numbers A common way of representing a number as a sequence of binary digits consists in viewing the number as an ordered set of decimal digits and representing each decimal digit with a combination of four bits according to a

specified code. A possible code for representing a decimal digit in binary form could be the one reported in Table 2.1. Thus, the number 378 would be represented as 0011 00111 1000

This coding way, commonly referred to as "binary coded decimal" (BCD) has a heavy drawback. Since the number of the combinations of four bits is 16 and there are only ten decimal digits, six combinations are assigned. Thus, for example, the sequence 1010 1111 is not used for representing any number. Therefore, the average number of binary digits used in this representation technique is larger than the strictly necessary one, and this results in a loss of efficiency. TABLE 2.1 Representation of a Decimal Digit in Binary Code DIGIT 0 1 2 3 4 5 6 7 8 9 CODE 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 10101 1011 1100 not allowed 1101 1110 llllj

This drawback is overcome by continuing the representation law indicated in Table 2.1 as shown in Table 2.2. This code is called "pure binary code", and is specified by the following relation. A sequence of binary digits an an_i ... a, ao . a_, a_2 ... describes the number N = an 2 n + an_, 2"- 1 + ... + at 2 + a0 1 + a_, 2 ' 1 + a_2 2" 2 + ... TABLE 2.2 Representation in Pure Binary Code DIGIT 10 11 12 13 14 15 16 17 1010 1011 1100 1101 1110 CODE

mi
10000 10001

Single-bit Arithmetic Binary arithmetic is based on single-bit arithmetic. The addition of two single bits, an augend bit and an addend bit, gives a sum bit and a carry bit according to the following rules: AUGEND BIT 0 + ADDEND CARRY SUM BIT BIT BIT 0 = 0 0

0 1
1

+ +
+

1 0
1

= 0 = 0
= 1

1 1
0

The multiplication of two single bits, a multiplicand bit and a multiplier one gives a single-bit product, according to the following rules: MULTIPLICAND MULTIPLIER PRODUCT BIT BIT BIT 0 x 0 = 0 0 x 1 = 0 1 x 0 = 0 1 x 1 = 1 These rules are the obvious applications of the well-known concepts of sum and multiplication to the binary arithmetic. Similar rules can be introduced for defining binary subtraction or division. The application of these rules to performing binary arithmetic is straightforward. For example, the sum of 101.01 and 100.11 can be performed as follows: 1 111 carry 1 0 1.01 1 0 0. 1 1

1 0 1 0. 0 0 Similary, the product of 110 by 101 is executed in the following way: 1 10 101 1 10 0 00 1 10 11110 Two-complement The two-complement of a given binary number N = a a,,., ... a! ao a useful concept for a widespread way to represent negative numbers is defined as follows. First the number
N* = 3n a n - i *i *
X

is considered, which is obtained from N by complementing any bit. Then the number 00 ... 01, having only one bit equal to 1 in the least significant position of N*, is added to N*, thus obtaining a result R which is the two-complement of N. For example, the two-complement of N = 0 1 0 1 1 0 0 is obtained as follows: First step: Second step: N* = 1 0 1 0 0 11 1 1 carry 1 0 1 0 0 11 + 1 R = 1 0 10 1 0 0

Representation of negative numbers One of the most widespread techniques for representing the whole field of the relative numbers is the twocomplement notation, which is defined as follows: Positive numbers A positive number is represented by a magnitude section containing the representation of the number in the pure binary code, and a sign bit, which is a bit 0, to be imagined at the left of the most significant bit of the magnitude section. For example, the number +3 is represented by SIGN BIT 0 Negative numbers A negative number is represented by the two-complement of the given number in the magnitude section and by 1 in the sign bit. For example, the number 1 is represented by SIGN BIT 1 Indeed, 11 is the two-complement of 1. As a more complete example, Table 2.3 presents the list of the codes used for representing the field of the integers from 4 to +3. Notice that the representation sn of a number (where s denotes the sign bit and n the magnitude section) can be interpreted to mean that the represented number is sx(-4) + n . The merits of this representation technique will be apparent after the properties of the two-complement arithmetic have been presented. TABLE 2.3 Representation of the Integers from 4 to +3 in Two-complement Notation NUMBER CODE 0 1 1 0 10 0 01 000 1 11 1 10 101 100 MAGNITUDE 1 SECTION 1 MAGNITUDE 1 SECTION 1

+3 +2 +1
0 -1 -2 -3 -4

Addition in two-complement notation The main advantage offered by two-complement notation is that the sum of two relative numbers can be performed by using an adder for positive numbers and interpreting the sign bit as a magnitude bit. This is shown in the following examples. Addition of a positive and negative number 0 11 1 10 00 1 00 1 1 1 1 1 Notice that the left-most carry is to be discarded. 000 (+ 3) + ( - 2) (+ 1) (+ 1) + ( " 1)
(0)

Addition of two positive numbers 0 10 0 0 1 0 1 1 0 10 0 11 10 1 (+2) + (+1) (+ 3) (+ 2) + (+ 3) overflow

Notice that in the second case the result is not correct, as is obvious, since the sum of +2 and +3 is outside the field of the represented numbers. This overflow condition is shown by the fact that the sign bit of the result is different from the sign bits of the two addends. Addition of two negative numbers 111 110 101 1 00 1 1 10 0 10 (-1) (-2)
3) ( (- 4) (

+2)

overflow

In the second case the result is not correct, because the sum of 4 plus 2 is outside the field of the represented numbers. Also in this case the overflow condition is shown by the fact that the sign bit of the result is different from the sign bits of the two addends. Summing up, the addition of two relative numbers can be performed by using the sign bit as the most significant of the magnitude bits, under the following two conditions: (1) the left-most carry is to be neglected; (2) the overflow condition may occur when the two addends have the same sign, and it is shown by the fact that the sign bit of the result is different from the sign bits of the two addends. Subtraction in two-complement notation The simplest way to perform subtraction in two-complement notation is to add the two-complement of the subtrahend to the minuend. On the other hand, the computation of the two-complement of a given number N involves the complementation of all the bits of N and the sum of the result and 1. It follows that both addition and subtraction require only an adder and a circuit for complementing the binary digits of a given number. Notice also that many registers have two complementary outputs for any stored information bit; therefore, complementing a bit corresponds merely to using the "complementary" output instead of the "true" output. Other operations. Hardware and software implementations As in the usual decimal arithmetic, the product of two numbers is the sum of a certain set of rows, each being obtained by multiplying the multiplicand by a digit of the multiplier and shifting the result a suitable number of positions. In the binary case the multiplication of the multiplicand by a digit d is a very simple operation, since the result coincides with the given multiplicand if d is 1, and it is always 0 if d is 0. Division and other arithmetical operations can be performed by using computation techniques which are the direct application to the binary case of well-known algorithms. All these operations can be implemented in "hardware" or in "software". We say that an operation is implemented in "hardware" when a circuit is avilable in the computer, which can perform that operation directly. When a command, or a suitable set of commands, are given to that circuit, the content of one or more input registers are read, the given operation is performed and the result or the results are delivered to one or more output registers. We say that an operation is implemented in "software", when the computer circuits can only perform elementary operations with respect to the given operations. This sequence constitues a "sub-program", which is written in a memory device using a suitable code.

10

Fixed- and floating-point representations In the representation techniques of the type above presented, which are usually referred to as "fixed-point representations", the field of the represented numbers is relatively small. When the field of the represented numbers is to be enlarged, it is necessary to use a representation technique of the type "floating-point", in which a part of the available code is used for indicating the position of the decimal point. In other terms, if reference is made to the expression of number N as N = A-2B . a first section of the code is used for representing A (usually, in two-complement notation) and a second section for representing B (generally, in the same way as for B). Generally, small-and medium-scale computers used in aerospace applications perform floating-point arithmetical operations in software, but there are also small- and medium-size avionic computers incorporating circuits for hardware floating-point arithmetic.

2.4

BOOLEAN ALGEBRA

Boolean algebra is the mathematical tool which was introduced by George Boole for investigating logical relations and is now widely applied to the description and design of digital computers. The basic concepts of Boolean algebra are very briefly summarized in this section. Boolean variables A Boolean variable is a quantity which may, at different time, have one of two possible values. The two values of a binary variable are denoted by " t r u e " and "false", or by 1 and 0. In the circuits of a computer, these two values are represented by two voltage levels, or by the presence or absence of a pulse, or by two physical states. When the value 1 is represented by the high level of a physical magnitude and the value 0 by the low level, the system logic is called "positive"; on the contrary, when the values 1 and 0 are represented by the low and the high value, respectively, the system logic is referred to as "negative". Logica] operators Many operators which specify logical operations on Boolean variables can be defined. Some of the elementary operators which are most widely used for describing complex systems is the following. Logical NOT The logical NOT, or complement, of a Boolean variable x is a new variable x' which is 1 when x is 0, and is 0 when x is 1. Boolean operators are commonly defined by means of tables which specify the value of the dependent variables as a function of any combination ot values of independent variables. These tables are usually referred to as "truth tables". The truth table for operator NOT is presented in Table 2.4. The complement of a variable x is often written as X. TABLE 2.4 Truth Table for Operator NOT

Logical OR The logical OR, or sum operator, of two Boolean variables x and y is defined by the truth table presented in Table 2.5.

II

TABLE 2.5 Truth Table for Operator OR

X

y 0 i 0 1

x OR y 0 1 1 1

0 0 1 1

This definition can be generalized to the case of many independent variables. The logical OR of n independent variables x,, x. xn is a new variable y which is 0 when all the independent variables are 0 and is 1 for any other combination of values of independent variables. Variable y can also be written as y = x, + x2 + ... + xn . Logical AND The logical AND, or product operator, of two Boolean variables x and y is defined by the truth table present in Table 2.6. TABLE 2.6 Truth Table for Operator AND
x 0 0 1 1 y 0 1 0 1 x AND y 0 0 0 1

The definition can be generalized to the case of many independent variables. The logical AND of n independent x n is a new variable y which is 1, when all the independent variables are 1, and it is 0 for variables x,, x. any other combination of values of independent variables. Variable y can also be written as y = x, . x2 xn . Logical coincidence The logical "coincidence", or COIN operator, of two Boolean variables x and y is a variable z which is 1 when x and y take the same logical value and is 0, otherwise. Therefore, this operator is defined by the truth table in Table 2.7. TABLE 2.7 Truth Table for the Logical Coincidence
x 0 0 1 1 y 0 i 0 i x COIN y 1 0 0 1

Logical EXOR The logical EXOR, or exclusive-OR operator, of two variables x and y is defined by the truth table presented in Table 2.8.

12

TABLE 2.8 Truth Table for Logical EXOR

x 0 0 1 1 y 0 i 0 1 x EXOR y 0 1 1 0

Notice that the truth table of logical EXOR differs from the one of logical OR only for the value associated to the fourth row. This comparison explains why this operator is called "exclusive-OR", whereas the OR operator is also referred to as "inclusive-OR". Notice also that the logical EXOR is the complement of the COIN operator Operator NAND The NAND operator is defined by the truth table presented in Table 2.9. TABLE 2.9 Truth Table for NAND Operator
X

y 0 i 0 i

NAND y 1 1 1 0

0 0 1 1

Notice that this operator, as the name NAND (NOT-AND) suggests, is the complement of the AND operator. The definition given in Table 9 can be generalized to the case of many independent variables. Operator NOR The NOR operator, as suggested by the name (NOT-OR), is the complement of the OR operator. Therefore, in the simple case of two independent variables, this operator is defined by the truth table present in Table 2.10. TABLE 2.10 Truth Table for NOR Operator
X

y 0 i 0 i

x NOR y 1 0 0 0

0 0 1 1

Implementation of a complex function by means of elementary operators Any Boolean function, which has been described by means of a truth table, can be easily implemented in terms of OR, AND and NOT operators. By way of example, let us consider the simple case of the Boolean function described by the truth table presented in Table 11. It is easy to verify that the output variable in the least significant of the two digits generated by a circuit performing the binary addition of three binary digits (usually, the digits of a certain weight of the two addends and the carry from the sum of the digits whose weight is smaller by one unit). Inspection of Table 11 shows that the output variable can be expressed as follows:
s = X.y.z+x.y.Z'+x.y'.Z'+x.y.z

where any three-variable product corresponds to one of those rows of Table 2.11 for which the output variable is 1. The circuit shown in Figure 2.5 corresponds to the above written expression.

13

TABLE 2.11 Truth Table of a Boolean Function

x
0 0 0 0 1 1 1 1

y 0 0 1 1 0 0 1 1

z 0 1 0 1 0 1 0 1

s 0 1 1 0 1 0 0 1

o S

X X y y z Z Fig. 2.5 Implementation of the function s = X.y.z + X.y.7 + x.y 1 + x.y.z

14

The same output variable can be expressed as a function of independent variables in a number of different ways. The problem of finding among the valid expressions the one corresponding to the circuit having the minimum number of elementary units is one of the most important in logical design. Its treatment would be outside the scope of this chapter; the reader interested in it can study References 1 3. It is not difficult to prove that the same output variable s can be expressed in the following form:

s -

[(/x)/(/y)/z)/[(/x)/y/(/z)]/[x/(/y)/(/z)l/[x/y/z]

where / denotes the NAND operator. The latter expression is formally the same as the former, with the exception that any operator in the former has been substituted by a NAND operator. Therefore, the latter expression contains only one type of operator and corresponds to a circuit having only one type of elementary unit in contrast with the circuit of Figure 2.5 using three different types of elementary units. This explains why NAND operators (as well as NOR operators possessing the same property) are so widely employed in binary circuits. Combinational and sequential circuits A binary circuit like the one shown in Figure 2.5, in which the output value depends only on the values taken by input variables at athe considered instant, is called "combinational". On the contrary, a binary circuit in which the output value depends on past values of input variables is referred to as "sequential". The counters, which will be described in the next paragraph, are examples of sequential circuits. In other terms, the difference between combinational and sequential circuits lies in the fact that the latter have a memory keeping track of the past history of the system. Analysis and synthesis of sequential circuits are more complicated than the corresponding problems for combinational circuits. The reader interested in them can read the works cited in References 13.

2.5 BUILDING BLOCKS From elementary units like the one we have so far described - flip-flops; AND, OR, NOT operators; NAND operators; etc., it is possible to build up more complex units, like the circuit shown in Figure 2.6 and performing the arithmetic sum of three binary digits. In their turn, also a set of complex units like the one shown in Figure 2.6 can be arranged in order to generate even more complex systems, and so on. Therefore, there is a hierarchy of complexity and it is very difficult the classify the set of systems and sub-systems. (Also classification on the basis of the size of the circuit is of no value, since as large-scale integration (L.S.I.) proceeds, more and more complex systems are placed in one chip.) The concept of the building block is a very relative one. However, what is here meant by building block is a sub-system of medium complexity. Many building blocks could be introduced at this point; the following list contains only those units which will be referred to in the following. The adder The medium-scale circuit shown in Figure 2.6 performs the arithmetic sum of three binary digits. The circuit can be sub-divided into two sections. The upper section, which coincides with the circuit presented in Figure 2.5, performs the computation of the less significant digit of the results, often called "sum". The lower section implements the function c = x.y + x.z + y.z and computes the more significant digit of the result, often referred to as "carry". The whole circuit is commonly called "full-adder" (F.A.). By a chain of full-adders, connected as shown in Figure 2.7, it is possible to implement a combinational circuit performing the addition of two binary numbers
x

and

n - l x _ 2 , > x l

Vn-1 Vn-2- - > Vl VO Such a circuit is called a "parallel adder", in that all the digits of the two addends are summed up in parallel. However, the result at the output leads s n , s n _ i , ... , s j , SQ will not be correct until all the carries from any fulladder to the following one have been propagated. This implies that the operation time of the adder will be the sum of the delays with which all the carries are determined. Since the computation of a carry requires two levels of elementary units, as shown in Figure 2.6, the sum of two n-bits addends will involve a computation time of 2 x n x T, where T is the delay time of an elementary unit. If T is equal to 10 nanoseconds and n is 16, 2 x n x T will be equal to 0.32 microseconds, which is a typical value for the operation time of a parallel adder.

1 5

O-

y oz o-

CIRCUIT REPRESENTED IN FIG. 5

-o s

AND

AND

Fig. 2.6

Example of implementation of a circuit performing the sum of three binary digits (full-adder)

Instead of using a chain of full-adders, it is possible to implement the addition by means of a single full-adder and a one-bit storage unit. The scheme of such a solution is shown in Figure 2.8. Here, the two addends are contained in two serial registers X and Y, while the result is stored into a third serial register S. A sequence of suitable commands are delivered as the SHIFT lines of X, Y and S; whenever a command is given at those lines a new bit is transferred toward the right end of the registers. The same sequence of commands is given to the one-bit storage unit, which is essentially a delay unit in the sense that at any SHIFT command the input received at the preceding command is delivered to the output. The system of Figure 2.8 is termed a "serial adder". Of course, serial adders are generally cheaper but also slower than parallel adders. The preceding consideration developed with reference to parallel and serial adder applies also to other parts of a computer. Many functional sub-units of a computer, like registers, transmission lines, multipliers, etc., can be implemented in parallel or serial form. Parallel solutions are faster but more expensive. The resulting speed-cost trade-off should be carefully evaluated, since a wrong choice for any unit may compromise the efficiency of the whole system. The switch A switch is a circuit that permits or prohibits the passage of a signal through a line or of a set of signals through a set of lines. The well-known relay is an example of switch. It is inexpensive and bistable, but it does not operate fast enough to serve in a high-speed computer. For this reason, switches in a modern computer are generally electronic. Figure 2.9 shows a simple two throw switch. It is a combinational circuit implementing the function a.c + b.C. Here a and b are the signals to be transmitted, and c is the command signal. It is apparent that the presence of signal c(c=l) throws the switch in the up direction, and the absence of c throws it in the down direction.

-O X

X,

< c n-2

Fig. 2.7

Implementation of a parallel adder

17

SHIFT

SHIFT

ONE-BIT STORAGE UNIT

Fig. 2.8

Scheme of a serial adder

Similar arrays using AND and OR elementary units can implement multipole switches and multithrow switches. A multipole switch can be imagined as a set of circuits like the one shown in Figure 2.9 operating in parallel; therefore, it affects several information paths. A multithrow switch is a generalization of the circuit of Figure 2.9 in the sense that it can route a signal to several distinct lines. Switches are among the most important components of a computer because they allow one computer subsystem to control the behavior of another sub-system.

The decoder In a computer, there is a frequent need for translation of a binary coded piece of information to a "one-outof-many" form. An example of this is the circuit shown in Figure 2.10. It has two input variables and four output lines. Each of these output lines has been assigned a binary code (00 to line 0, 01 to line 1, 10 to line 2, 11 to line 3). When a code word is presented at the two input lines, the corresponding output line is excited and all the other ones take the value 0. The symbol for the decoder is shown in Figure 2.11.

18

a.c + b.c

Fig. 2.9

Scheme of the two throw switch

AND

0 (00)

AND

1 (01)

AND

2 (10)

3 (11)

Fig. 2.10

A simple example of decoder

19

*,
9*

__>

\
% *

Fig. 2.11

The symbol for the decoder

The encoder The encoder provides the inverse function of the decoder. It has a number of input lines, only one of which may be excited, and produces at the output the binary code corresponding to the input line excited. The symbol for the encoder is shown in Figure 2.12.

*^~

E
0 9

N.
X*

>

Fig. 2.12

The symbol for the encoder

The counter A counter is a device which is fed with a pulse train in time and delivers a signal combination in space, forming a coded number which indicates how many pulses have been received at the input after the counter was last reset to zero. The symbol for the counter, which is a typical sequential circuit, is shown in Figure 2.13. In addition to the count line C, receiving the pulse train, there is a reset line R, which may reset the counter to 0 regardless of its present state. If the counter can count up to N, upon receiving the N" 1 pulse it is reset to zero.

C
Fig. 2.13

The symbol for the counter

20

2.6 THE ARITHMETIC UNIT A typical arithmetic unit contains some registers, some switches, a set of circuits performing arithmetic operations, a small control unit and other elements of minor importance. A very simple scheme with two registers and two switches is presented in Figure 2.14.

r^N REGISTER A
_E
1

r~\

CIRCUIT
(_>

_ _ _ : <_>
1
i

FROM THE MEMORY

3 oo

ii

3 OO

REGISTER B

TO THE MEMORY

i i i _i

ARITHMETIC UNIT CONTROL

FROM AND TO THE CONTROL UNIT

Fig. 2.14 Scheme of the arithmetic unit

Registers hold operands, intermediate results and final results. The number and the tasks of registers vary from computer to computer. Very simple computers may have only one register, called "accumulator". Mediumscale computers may have from two to five or six registers. Typical of a pair of registers is the function of holding the divisor and the quotient during division. Large-scale computers may have up to few tens of registers variously organized. An important register which will be presented later is the index register, used for a special technique of addressing. Switches control the flow of information from one register to another, either through the circuits performing arithmetic operations. What we mean by "circuits" is the system of the units performing arithmetic operations. In the very simple case of Figure 2.14, the circuits may consist uniquely of a serial or parallel adder. In more complex computers this building block may compromise very sophisticated units such as, for example, a facility for performing in hardware floating-point multiplication. The arithmetic unit control is a special unit which supervises the activity of the arithmetic unit. When informed of the instruction to be executed from the control unit of the computer, this small control times and monitors the process.

21 Other elements of minor importance are also required. For example, a counter may indicate how many bits have been already summed up in a serial adder. Other indicators summarize the state of the system or the occurrence of some particular events. For instance, a one-bit indicator is used for storing the information that overflow has occurred in the last executed addition.

2.7 THE MEMORY The main types of memory devices The most popular memory device is the ferrite core memory. It is built up of ferrite cores, one per bit. Indeed, ferrite has a nearly rectangular hysteresis cycle; so two stable states are possible when the core is not excited, and each of these states is assigned a binary value. Most modern cores have a diameter less than 20 mils. Cores are usually wired together to form square or possibly rectangular matrices in which each matrix contains as many cores as there are words in the memory bank. A set of parallel matrices forms a bank, in which each matrix corresponds to a bit position in the memory word. The capacity of a ferrite core memory ranges from few thousands to several millions of bits, and the time required for reading or writing a word varies from few hundreds of nanoseconds to few microseconds. The principle of using the two magnetization states of a small element is applied in a number of other magnetic storage devices. The most common of these magnetic storage media is magnetic tape; but also magnetic disks, drums, cards or strips are widely used. The capacity of these memory devices may be very large, but the average time required for reading or writing a word is much larger than the one of a ferrite core memory and depends on the position of the datum on the magnetic medium. Storage organization In general, a computer memory is organized as a set of cells or positions, each of which is specified by an address. The address should not be confused with the content of a cell; the former is a unique label for the cell, the latter may vary during the operation of the memory. It is customary to distinguish between sequential access memories or serial access memories, and direct access memories, or parallel access memories or random access memories. Examples of sequential access memories are magnetic tapes or disks. In them the records must be written and read in sequence, and, therefore, the access time, namely the time it takes to find a memory block and write into it or read from it, varies somewhat depending on where the required data are situated with respect to the last called data. A core memory is an example of random access memory. In it any part of the memory can be reached in approximately the same time, regardless of where the record is situated relative to the record which was last read or written. Sometimes, it is necessary to distinguish between primary memory and secondary memory. A primary memory is fitted into the organization of the computer in such a way that it can exchange information directly with the control unit and the arithmetic unit. Generally, each cell in primary storage can be specified with one instruction. A secondary memory cannot exchange data with any unit other than primary memory. In general, an individual cell in a secondary memory cannot be specified with one instruction; information is transferred in larger blocks between primary and secondary memory. The system with primary and secondary memory is a simple example of hierarchical storage organization. The need for a hierarchy in storage organization derives from the different costs of the different memory devices. Thus, for example, a core memory is rather fast, but it has a cost per bit relatively high. A disk memory is characterized by a smaller cost per bit but a larger access time. In a typical solution a core memory is used for primary storage and a disk memory for secondary storage. Those data which are often used during a certain computation are stored in the primary memory, while those data blocks (numerical data or programs) which will be used later are held in the secondary memory. They will be transferred into the primary memory before they are to be used in the execution of a computation. Another type of two-level organization is frequently used in avionic computers, whose main features are to be very small size, low power dissipation and light weight. In these systems the following two types of storage are used: (1) A primary memory consisting of relatively few flip-flop registers. This small, very fast memory, which is well suited for data and instructions that are going to be used very often, is sometimes called a "scratch pad memory". A secondary memory consisting of relatively many one-bit storage devices, into which the computer cannot inscribe information.

(2)

22

The electronic technology used for this type of storage device, generally based on metal-oxide transistors, allows a small integrated circuit to contain a relatively large amount of memory. This type of memory, generally called "permanent memory" or "read-only memory" (ROM), will be used for the permanent storage of programs or numerical constants of computation. The elements of a random access memory A core memory, as well as a large solid-state memory, can be represented with the block diagram of Figure 2.15. The basic elements of such a system are: the cells, the memory address register, the memory data register, the memory control unit.

MEMORY ADDRESS REGISTER

MEMORY CELLS MEMORY DATA REGISTER

RECALL/MEMORIZE START DONE MEMORY CONTROL UNIT

Fig. 2.15

The organization of a random access memory

As mentioned above, the cells are arranged in a two-dimensional array. Each cell holds an ordered set of bits or word, which is not destroyed by a recall operation. However, a new word may be written into a cell at the expense of destroying existing information. The time necessary for memorizing or recalling a word is independent of the address of the cell and is called "cycle time". The memory address register holds the address of the cell with which the memory is currently concerned. The content of this cell is transmitted from some other unit of the computer. The memory data register holds a datum. During a recall operation, the information from the cell pointed to by the memory address register is placed temporarily in the memory data register by the memory control unit. It is available to the requesting sub-system when the done line becomes on. During a memorizing operation, the datum to be stored is placed by the originating sub-system into the memory datum register by a suitable command signal. Then it is transmitted to the cell pointed to by the memory address register by means of a suitable command delivered by the memory control unit. The memory control unit controls the memory cycle. It is instructed by the requesting unit either to recall or memorize. After the start signal is received, the memory control unit keeps the memory address register and the memory data register locked out from interference by other sub-systems until the whole job is completed. The memory control unit finds the cell and times the flow of information between the memory data register and the chosen cell. When the job is completed, the memory control unit issues a completion signal indicated in the figure as done.

23 2.8 THE CONTROL UNIT Function The control unit supervises and coordinates all the operations of a computer including those of the arithmetic unit, memory, input/output devices, as well as its own. Depending upon the organization of the computer, the control unit may or may not be able to relinquish its autonomy to one of the other sub-systems. Even when it does so, the sub-system in question returns authority to the control unit when the sub-servient sub-system has completed its operation. Complete directions are supplied to the control unit by the program, the sequence of instructions or commands. These instructions or commands are memorized in the memory together with numerical data and are recognized and interpreted by the control unit as this encounters them. Since each instruction is comprehensible to the computer but may not be directly reasonable by the human, this sequence is called the "machine language program". Operation The control unit operates in two cycles, fetch and execute. In the fetch cycle a new instruction is brought from the memory to a location in the control unit where it is examined and interpreted. With some exceptions, the control unit gets its next instruction from the memory location right after the one where it got its last command. In the execute cycle, the control unit interprets and performs the instruction it has fetched. Usually, the execution of an instruction requires at least one operand which is held in the memory. The control unit sets up the destination for receipt of the new operand, and, when this is passed over to the destination sub-system, it instructs the sub-system what to do. When the destination sub-system has completed its task, a new fetch cycle is begun. The structure of the control unit The structure of the control unit is presented in Figure 2.16. The instruction counter is a register which stores the address in the memory of the current instruction. As a rule, the sequence of the instructions is stored into a set of adjacent cells, so that the content of the instruction counter may be increased by one unit at the completion of any fetch cycle. Only a limited class of instruction the "branch" instructions require a content different from the increment by one unit to be introduced into the instruction counter. The one-bit storage device F indicates which cycle of operation fetch or execute - is in progress. During the fetch cycle Switch 1 transmits the content of the instruction counter to the memory address register, so that the new instruction is read from the memory and brought to the memory data register. During the fetch cycle, after the new instruction is received, the content of the memory data register is transferred to the instruction register. Usually, an instruction consists of a number of distinct parts. A section of the instruction contains the "operation code" indicating which type of instruction is to be executed. Some distinct sections contain the addresses of the memory cells holding the operands or other data (for example, in the branch instructions, the address of the instruction to be executed next). In the simplest case, each instruction refers only to one operand, so that there is only one section containing an address. Finally, other sections may contain supplementary information. The decoder works during the execute cycle. It examines the section of the instruction register holding the operation code, and excites at the output the line corresponding to the type of instruction to be executed. The instruction encoder interprets the signals produced by the decoder, chooses the sub-systems which are to be informed and sets up the flow of information to them. Notice that during the execute cycle the content of the address section of the instruction register is transferred to the memory and brought to the memory data register. Usually, this data will be transferred to the arithmetic unit through Switch 2. The Repertoire of the Instructions In a first, rough classification, whose intent is merely to give an idea of the instruction repertoire, we can distinguish between the following classes of instructions.

24

MEMORY MEMORY ADDRESS REGISTER

MEMORY DATA REGISTER

TO THE + ARITHMETIC UNIT

-C

SWITCH

3
INSTRUCTION

c
REGISTER

SWITCH
*y -.

INSTRUCTION COUNTER

DECODER

INSTRUCTION ENCODER

T
Fig. 2.16 Scheme of the control unit

25 Transfers The content of the cell whose address is specified by the address section of the instruction is to be transferred to a certain register (usually, of the arithmetic unit). Arithmetic (or logic) operations The content of the cell whose address is specified by the address section is to be submitted to a given arithmetic (or logic) operation together with the content of a certain register. Shifts The content of a specified register is to be shifted to the right or to the left. The number of shifts to be executed is usually indicated in the address section with a certain code. Jumps The content of the address section is to be transferred to the instruction counter. Sometimes the indicated jump must be executed only if a certain condition - for example, the equality to 0 of the content of a specified register - is satisfied (conditional jump). Output operations The content of a certain register (for example, the main register of the arithmetic unit) is to be transferred to the interface register of a specified output device, which is indicated in the address section of the instruction. Input operations They are similar to the preceding output operations. Indexing and indirect addressing Let us assume that, as is often the case, the length of a memory cell (and of an instruction) is equal to 16. If 6 bits are devoted to the operation code, which will distinguish 2 6 = 64 different instructions, only 10 bits will remain available for the address section. It follows that, even in the case of one-address computers, only 2 1 0 = 1024 different memory cells can be referred to in an instruction. Since the memory size may be much larger than 1024 cells, it is necessary to devise some method for referring to the whole memory. Two of the most common techniques for extending the addressing capabilities of instructions are the two following ones. Indirect addressing In this mode of addressing, an instruction-contained storage address does not specify the location of an operand; instead, it specifies a location that contains the address of the operand. Therefore, the whole length of a memory cell is devoted to indicating an address. This means that, in the case of a memory length equal to 16, 2 1 * distinct addresses can be distinguished. Notice that if both direct and indirect addressing modes are desired, one bit in the instruction must be devoted to indicating whether the- address specified in the operand field is to be interpreted as the address of the operand or the one of the cell containing the address of the operand. Indexing An index register is a hardware register, usually of the same length as the memory cell, whose content can be added to or subtracted from the address written in the operand-field of an instruction for obtaining the true address where the operand will be found. Of course, the instruction code must contain a bit indicating whether or not indexing must take place. Besides extending the addressing capability of a computer, indexing can greatly simplify programming by facilitating the handling of loops, arrays, and other repetitive processes. Some computers have a number of index registers and facilities for modifying and using each of them separtely. Microprogram ming Many modern machines are often designed applying the concept of "microprogram control". In such machines each instruction, instead of being used to initiate control signals directly, starts the execution of a sequence of "microinstructions" at a more elementary level. The microinstructions are usually stored in a special read-only storage unit. Thus, the instruction repertoire of a microprogrammed computer can be altered to suit particular requirements by simply changing the stored microinstructions.

26 2.9 INPUT-OUTPUT DEVICES Operation An input operation begins when an input instruction is read by the control unit and a command is sent to an input device to read a set of words or "record". Reading takes place by having an input medium (e.g., a punched card) move through the input device. Information is read and converted to the code used by the computer system. The coded information is transmitted to the internal storage and stored into locations assigned to hold the input record. The data are then available for use by the processing instructions. An output operation is essentially the reverse of the preceding one. The data to be written are arranged by program instructions in storage locations assigned for this purpose. An instruction to perform output causes the data from the output storage locations to be copied and transmitted to the output device. An input or output device is directed by a device control unit. This relatively small control unit decodes the command from the computer control unit and effects operation of the device or devices. In some cases other operations, such as, for example, checking of transmitted data, are performed. The connection between the central processor and the device control unit is, in most large-scale computers, via a "channel". This is essentially a control unit for the system of some input-output device control units. The task of the channel is essentially to control the input-output paths by which data are brought into and out of the primary storage. The Principal Input Devices The following is the list of the main input devices. Teletype Information is read from the keyboard or from the well-known paper tape. A typical reading speed is 10 characters (of 8-bits each) per second. Paper tape reader Reading speed ranges from 350 to 1000 characters/second. Punched card reader The medium where information is written is the well-known card having 80 columns into each of which a character is written. The typical rate of speed varies from 300 to 1200 cards/minute. Analog-to-digital converters If an analog quantity is to be processed by digital equipment, an analog-to-digital converter must be connected between sensor and computer. One kind of converter is based on comparing the sample of the input signal (at a given instant of time) with a reference voltage which varies with time. An electronic counter, connected to a clock generator, counts the number of clock pulses elapsed before the reference voltage reaches the level of the analog voltage. Accuracy and speed of analog-to-digital converters are rather variable. Typical values are perhaps an accuracy equivalent to 1 part in 2 10 parts and a speed of 50,000 samples per second. The main output devices Teletype Output information is either punched on the paper tape or printed. A typical writing speed is 10 characters/ second. Paper tape punch Punching speed ranges from 20 to 150 characters/second. Card punch Punching speed ranges from 100 to 500 cards/minute.

27

Line printer Writing speed varies from 200 to 1500 lines (of 120 characters each) per minute. Video displays They are used as output devices as well as input devices by means of a suitable light pen. Digital-to-analog converters In process-control applications like many of the air-space applications, heavy reliance is placed on digital-toanalog converters which make it possible to convert a sequence of digital data into a continuous signal. In general, realization of digital-to-analog converters does not offer heavy difficulties. Interrupts and cycle-stealing Consider the simple case of a fast paper tape reader. If a reading speed of 1000 characters/second is assumed, the time required for transmitting a character from the device to the memory of the computer is 1000 microseconds. Almost all this amount of time is spent in mechanical and electrical operations leading to writing the information which has been read from the paper tape into the interface register of the device. Instead, only few tens of nanoseconds are sufficient for transmitting information from the interface register to some register of the arithmetic unit (or even, in some cases, to the memory data register), and a time of the order of some hundreds of nanoseconds is required for storing information into the memory from the memory data register. A way to prevent all the computer from remaining idle during the operation of the input device is described below in its successive stages. (1) When in a program the order of reading a record from the paper tape is to be given, an instruction is written which starts the operation of the reader. It is the control unit that interprets this instruction and delivers to the device the command starting the motion of the tape and the other mechanical and electrical operations of the device. As soon as the starting signal has been transmitted, the control unit, without waiting for a character to be read from the tape, picks up another instruction, interprets it and starts its execution. Thus, while the reading operations are performed, the program execution is continued in parallel. No sooner a character has been read from the tape and transferred to the interface register of the device, than the latter sends a reading request to the control unit through a suitable interrupt line. Upon receiving an interrupt request, the control unit stops the background program and begins the execution of a routine which transfers the datum from the interface register to some register or memory cell and possibly performs other operations. This interruption routine has been written in some memory area. The first cell of this area is to be known by the control unit. This is achieved by writing in a fixed memory cell the address of the first instruction of the interruption routine. (4) At the end of the interruption routine, a jump instruction to the background program is executed, exactly where the background job was interrupted.

(2)

(3)

In order to reduce the time spent in the input/out operations, sometimes all the operations listed in 3 and 4 are performed in hardware without the intervention of an interruption routine (direct memory access: DMA). In this case the transfer is performed through special channels which steal time slices from the control unit whenever necessary. During each stolen time slice one transfer is performed. The computer logic performing the direct memory access is basically independent of the logic involved in the programmed transfer. The main point is that the DMA does not perform the transfer via a register of the arithmetic unit. Rather the transfer is performed via the memory data register directly with the computer memory. Since the program execution is not involved in the DMA transfer, the computer working registers are not disturbed. This kind of transfer is also known by other names, such as data channel, data break, and cycle stealing transfer.

2.10 SOFTWARE Software is the collection of program and sub-programs associated with a computer which facilitate the programming and operation of the computer. These service programs do not solve the user's problem directly, but are employed as components of his program. They are generally designed not by the user, but by the system programmer. The basic elements of software are listed overleaf.

28

Assemblers Most programming today is not done in machine language, which is cumbersome and lengthy. Assembly systems represent the first step for overcoming the disadvantages of machine language. Programs are written in an "assembly language" which is very similar in structure to the machine language but differs from the latter essentially for two reasons: (a) the programmer can specify the instruction code by a mnemonic symbol rather than a numerical code; (b) the memory cells can be specified by symbolic names rather than their addresses. An assembly language is an example of "source" language. It requires one or more stages of translation to produce the machine language program. The basic tool for performing this translation is the "assembler" which is a suitable program (in machine language) "assembling" programs written in an assembly language to produce machine language programs. Compilers Assembly languages have the characteristic that each source language command is represented by exactly one machine language instruction. This is the reason why an assembler is a softwear tool relatively simple to be produced. But programming in an assembly language, although it is less cumbersome than programming in the machine language, still remains a lengthy task. For that reason, other types of source language have been introduced, which are characterized by commands (such as the computation of functions or complex operations in floating-point) each involving many machine language instructions. These languages convey information with a syntax and word structure similar to that used by the programmer in expressing himself when he describes his algebraic or business problem. Examples of such languages include FORTRAN, ALGOL, PL1, COBOL. A program wirtten in a high-level language, such as FORTRAN, is translated into a machine language program by means of a suitable program called "compiler". The compilation process usually involves examining and making use of the overall structure of the program. Relocation, linkage and loading At assembling or compilation time, it is sometimes not known where in memory the program will be placed for execution. Thus, some of the addresses in the instructions cannot be definitively assigned. Therefore, in such cases the assembler or the compiler produces only relative addresses, or, more specifically, addresses relative to zero, i.e., addresses which will be used if the first word of the program is placed in the first cell of the memory. When the program is to be loaded into memory, starting in cell x, it has to be "relocated". This simply means that x is added to all addresses which have been tagged as being relative. This holds in particular when the program is composed of a main section and a number of sub-programs. It is convenient for each sub-program to be compiled separately, so that it can be used in other programs without being re-compiled. But at compilation time it is known neither where the first instruction of the sub-program will be placed nor which memory cells in the main section of the program or in other sub-programs will be devoted to variables which are to be used in the present sub-program. Therefore, a set of sub-programs which have been compiled separately are to be "linked" together. Linkage is generally performed by the same program that transfers programs written in machine lanaguage on some medium, (paper tape or card, magnetic tape or disc) to the main memory prior to the execution of the program. This program is usually called "loader". But in many medium - or large-scale computers the two operations of linking and loading are executed separately by two programs, called "linkage editor" and "loader", respectively.

REFERENCES
1. McCluskey, E.J. 2. Marcus, M.P. 3. Miller, R.E. 4. Flores, Ivan, 5. Gear, William, C. Introduction to the Theory of Switching circuits. McGraw Hill, 1965. Switching circuits for Engineers. Prentice Hall, 1965. Switching Theory. John Wiley, 1965. Computer Organization. Prentice Hall, 1969. Computer Organization and Programming. McGraw Hill, 1969.

29

6. Foster, Caxton, C. 7. Chu, Yarham 8. Beizer, Boris 9. Stone, Harold S. 10. Weitzman, Cay

Computer Architecture. Van Nostrand, 1970. Introduction to Computer Organization. Prentice Hall, 1970. The Architecture and Engineering of Digital Computer Complexes. Plenum Press, 1971. Introduction to Computer Organization and Data Structures. McGraw Hill, 1972. Aerospace Computer Technology Catches up with ground gear. pp. 112-119, September 1972. Electronics,

30

CHAPTER 3 DATA ACQUISITION AND COMMUNICATION FUNCTION Yngvar Lundh 3.1 TYPICAL DEVICES TO WHICH AN AVIONICS COMPUTER IS CONNECTED An avionics computer is, by definition, part of a real time system, either in the air or on the ground. It therefore has to communicate with the rest of the system. To communicate is to exchange data in one form or another. In this chapter we shall discuss various aspects of such data exchange. First, let us briefly review some typical devices which may be part of an avionics system, and how these would communicate with the computer in some example cases. Operator communication is perhaps the most obvious. Human operators will need communication for supervision and/or interaction with the system. (The man-machine interaction function is discussed in more detail in another chapter.) For this there may be a series of switches, pushbuttons, lamps and displays or specialized indicators, pointer or dials. Handles, joysticks, "tracker-balls", as well as light pens or other graphical means may be used for input. For drawing the operator's.attention to special situations, alarm conditions, etc., flashing lights, audible tones, bells or even synthesized or prerecorded voice messages are available. All these devices can be used as computer inout devices, suitably arranged to fit a given set of needs. To relieve the mental load on the operator, it is often practical to arrange for the computer to request information when needed, rather than wait for the operator to remember, and to state the choices to be made or to suggest actions already computer-optimized, but needing operator sanction. Communication to process variables may typically be arranged as in the following examples. E.g., navigation and guidance accelerometers. The quantities measured by these devices must be encoded into a form suitable for entry into the computer. These quantities will for example be angular positions of gimbal rings, electric currents in servo compensating devices, etc. The throttle control of an aircraft might be a handle with an angle measuring device giving the throttle position as a number to the computer. Connection to these or more complex sub-systems may all be put into a general class of "sensors". Exchange of information between aircraft and ground installations may be required for guidance and control or other purposes. Computers may thus talk to each other over radio links, or a computer may have remote control of actuating devices, or receive data from remote sensors via radio or other transmission media. 3.2 DATA TYPES, FORMS AND FORMATS Physical quantities may be represented in an avionics system in two ways: analog or digital. Digital means "numeric" i.e., representing a quantity by a number (of units). Analog is what most of the real world is, namely continuous variable quantities. The name "analog" may be understood as one physical quantity representing another by behaving in an analog manner. The speedometer needle in a car gives an analog representation of the velocity while the mileage counter gives a digital representation of the travelled distance. Data in digital form are discrete in nature. A number consists of a definite number of digits. Each digit may attain a definite number of values: ten for a decimal digit, two for a binary digit. A binary digit is called a bit. Most digital systems use the binary number system, where the series of positive integers are 000 00 1 0 10 0 11 100 zero one two three four etc.

Decimal numbers may often be used indirectly by representing each decimal digit by a binary code, for example (straight binary coded decimal or BCD representation):

31

IMAL 0 1 2 3 4 5 6 7 8 9

BCD OOOO 0001 00 1 0 001 1 01 00 0101 0110 0 111 1 000 1 00 1

Many other coding schemes are in use for various purposes. A collection of bits representing a number is often referred to as a "word", and the number of bits in each word as the "word length". A word may be subdivided into groups each representing a decimal digit or a binary coded alphanumeric character. A string usually of 7, 8 or 9 bits is often referred to as a byte, and may typically be used to represent a coded alphanumeric character. See section on "Data Transmission". On transmission paths, within parts of a system or in sequential logical nets, operations may be serial, i.e., bit by bit, or parallel, i.e., one word at a time, or some combination of .these. Since most physical quantities of the real world are experienced as analog, a digital computer needs to have data converted. Various conversion methods are available. Analog to digital- and digital to analog conversion is discussed in some detail in the section on 'AD and DA Conversion". One operation which is necessary when converting an analog quantity to digital form is sampling. That is to take measurements (samples) at regular intervals (sampling interval). Each sample is converted to a number. An analog function of time which has thus been converted to a string of numbers is referred to as a time series. 3.3 CHARACTERISTICS OF DATA Taking an analog quantity which plays a role in a system which we want to deal with, various characteristics are important. The main parameters are: Bandwidth: How fast does the quantity vary with time? This can be specified as the (energy versus frequency) spectrum. "Bandwidth is the frequency range where the signal has significant energy content". Range: What are the minimum and maximum values which the variable will attain? Accuracy: With what precision are we interested in knowing the absolute value of the quantity? This can be stated in units (millimeters, degrees, etc.) or as a fraction of the range (per cent, parts per million, etc.). Resolution: With what detail are we interested in observing small variations? This is similar to accuracy, but refers to differences between two values of the quantity taken within a limited time span, or a limited area of the range, rather than their absolute value. Linearity: To what extent is there proportionality between two quantities where one represents the other? Linearity may be a highly desirable factor in many cases. In other cases, nonlinear representation may be desirable. Examples are logarithmic scales, saturation characteristics, etc. Data in digital form are discrete in nature. A number consists of a definite number of digits and each digit may have a definite number of values; ten for decimal digits, two for binary digits. Certain basic relationships exist between the main parameters, which we shall review in the remainder of this section. According to the sampling theorem - the full information content of a continuous function of time with bandwidth f, is present in a string of samples taken with frequency (sampling rate) fs ^ 2f . In other words: the original function may be reproduced exactly from a string of samples if the sampling theorem is obeyed. Note, however, the following two practical considerations which are very important: (a) When sampling a function at a sampling rate fs the highest frequency occurring in the signal must be f = 1/2 f, . It is not sufficient that the highest frequency of interest is below that limit. If there is noise

32

of a higher frequency, it will be "folded" down into the interesting frequency band, Therefore, a signal must usually be lowpass filtered before sampling. (b) To say that a spectrum does not contain energy beyond a certain limit is, of course, an approximation. In real life spectra will be shaped by filters having a finite "roll-off. In practice, one must therefore sample at a higher rate than the theoretical minimum. How much higher, depends on what residual noise level which can be tolerated, and is typically a compromise between filter complexity and further processing complexity of the time series. Accuracy and resolution is degraded in the conversion process between analog and digital data. However, data are always only required with a certain specific accuracy and resolution for any specific purpose. Noise in one form or another, including quantization noise will be tolerated below that limit. In conversion to digital form, the range of a variable is divided into a number of discrete values, i.e., quantized. Linear quantization would mean that the step or quantum from one value to the next would be constant over the whole range of the variable. If the total number of steps is N ; the resolution is (100/N)%. For quantization into N steps to be accurate is (100/N)%, the error in the quantization must be less than one half step; "error" then meaning departure from the ideal or nominal quantization "staircase function", see Figure 3.1.

HUMERI- ' 1 CAL VALUE

7
6

5
1.

3
2

1 0 1 A INPUT RANGE VARIABLE A-B 1 B

m *

1 1 1 1 0 0 0 0

1 1 0 0 1 1 0 0

1 0 1 0 1 0 1 0

y
BIT

y/j

T H R E E - BIT BINARY CODE

WEIGHTED PATTERN

Fig.3.1

Basic digital representation of a variable

A binary number of n bits can have 2 n different values, and this represents values with a resolution of N = 2 n levels. For example to represent a variable with a resolution of 0.1% in digital form, means quantizing into at least 1000 levels. This can be encoded by a digital number of 10 bits, since 2 10 = 1024 . If we wanted to represent a function of time having a bandwidth of f = 4000 Hz to an accuracy of 0.1%, we would need to sample at a minimum of fs = 2f = 8000 Hz and each sample must be represented by 10 bits. The resulting data stream would be 8000 10-bit words per second, or 80,000 bits per second. Straight binary coding, as we have assumed here, is in general an efficient method of coding, i.e., it requires few bits. In practical situations other codes may be chosen, which will increase the data rate in bits/second. For example if data are to be directly readable by human operators, a lot is to be said for binary-decimal coding, which is still a reasonably efficient coding scheme, but where 0.1% accuracy would mean 3 decimal digits, coded into 12 bits. Many other coding schemes which are in use have an even much higher degree of redundancy. Redundancy may be used systematically for various special purposes such as making the system more resistant to failure, by automatic error detection and correction. These and other practical matters will increase the bit rates from the theoretical minimum. 3.4 AD AND DA CONVERSION In this section we shall discuss conversion between analog and digital representation in further detail. Figure 3.1 shows how a range of a variable can be subdivided into n (here = 8) equal steps, and how these can be numbered.

33

We see that the individual bits of this straight binary code carry a certain weight. The first and most significant bit tells whether the value is in the upper or lower half, i.e., the weight of that bit is one half the total range. The next weighs one fourth, etc. A digital to analog (D/A) converter makes use of this. The input to a DA-converter is a digital number or "word", the output is typically an analog voltage, i.e., a voltage proportional to the number. Figure 3.2 shows the principal parts of a DA-converter. The bits control switches connecting or disconnecting "binary weighted" resistors to a summing amplifier, such that the output voltage is proportional to l/2bj + l/4b 2 + . . . 1/2".b n where bj is the i* bit of the n bit number. (Different circuit configurations may be used to obtain the weighting than the example shown in Figure 3.2.) To understand this, note the following main facts: the high-gain summing amplifier will produce an output voltage which makes the summing point zero volts. This will be the case when the current in the Rf just balances the sum of the currents in all the summing resistors.

REFERENCE VOLTAGE

SUMMI NG / R E S I S TTORS t

K_

"

FEED-BACK RESISTORS

2R

b2 o -

-N^ZIh
ANALOG ) OUTPUT VOLTAGE

"MR

t
SWITCHES CONTROLLED BY INPUT BITS

SUMMING

POINT

Fig.3.2

Digital to analog converter

An analog to digital (A/D) converter may make use of a DA-converter in a feed back loop as shown in Figure 3.3. The "control" has the task to find a binary number ("digital output") which when converted to analog is less than one half step different from the input voltage. It can do so by using the information "too big", "too small" or "tolerable" which comes from the comparator. Various strategies or methods are used for implementing these, and are readily implemented by electronic circuits. Let us now as an example consider an AD-converter working on the principle of "successive approximations". The conversion will then take place on n steps for an n-bit number: Step 1: The controller tries the number 100 whether this number is too large or not. 0, i.e., one half the range. The comparator decides

- Step 2, 3 . . , n 1: If previous number was too large, reset the "one" entered in previous steps to 0. In any case, set next bit to "one". Then decide whether this number is too large or not. - Step n : If previous number was too large, reset the bit enetered last. In this conversion principles, the AD-conversion times will be n . [(DA-settling time) + (comparison time)] Typically, the conversion time is a few microseconds per bit.

34

ANALOG INPUT

COMPARATOR

CONTROL

'f
DACONVERTER

Ii

II 1 ' DIGITAL OUTPUT

Fig.3.3 Analog to digital converter

For the general case, this is the most efficient scheme. There are, however, special cases where other methods are more desirable or more efficient. Assume for example that it is known that the variable has only changed a small amount since last conversion. It may then be more efficient to replace the successive approximation type controller by a bidirectional counter, counting up or down as decided by the comparator. This latter principle actually opens up for review the fundamental characteristics of bandwidth and accuracy discussed in the previous section; there are practical cases where incremental coding schemes have merit (i.e., coding the difference from one sample to the next). This becomes especially attractive at sampling rates significantly higher than twice the bandwidth. The theory of such coding schemes has been analyzed in great detail in connection with "delta modulation". A general limitation of incremental coding is that a single error - or the lack of a defined starting point makes the absolute value uncertain. This is tolerable in many cases, e.g., when the frequency response does not have to inlude "DC". For normal conversion (i.e., non-incremental), the main performance characteristics are accuracy (or resolution) and conversion time. For the DA- converter in Figure 3.2, the conversion time is the time from the digital number is made available at the bit inputs until the analog output value has "settled to" one half step or less from its nominal value. This is referred to as "settling time". DA-conversion is much faster than AD-conversion in the typical case. Let us return for a moment to the principle of digital representation of analog variables as depicted in Figure 3.1. Nothing was said about polarity of the input variable. The normal procedure to apply in the case that the input can be both positive or negative is to call the most significant bit the sign-bit. Note that the various representations of positive and negative numbers can be obtained by subtracting half the range (binary 100) from each variable: POSITIVE 1 1 1 1 10 101 1 00 0 1 1 0 10 00 1 00 0 MAX POSITIVE AND NEGATIVE 0 1 1 0 10 00 1 0 00 1 11 1 10 101 100

MIN

In the case of l's complement notation, "plus and minus zero" have equal value. This contraction of the scale is obtained by making the weight of the most significant digit one quantizing step less than half the range. The reference enters into all conversion schemes in an essential role, namely that of the "yardstick", or the definition of the measuring unit. If it is required to have "zero" correspond to zero voltage (i.e., the summing point in Figure 3.2), the most significant summing resistor may be referred to a secondary reference voltage of opposite polarity. In the discussion so far, we have assumed that the variable to be converted is intermediately represented by analog voltage. Although probably the most common, this is by no means always the case. One type of variable which is frequently occurring is angle. Shaft position is, of course, important in many automatic systems. In servo systems, for example, shaft positions are often represented by relative amplitudes between two or three AC voltage having specific phase relationships, as generated by "synchros" and "resolvers". Circuits are available for direct conversion between synchro and resolver signals and binary coded representation - thus exploiting the high

35 accuracy available in these, relatively rugged and compact electromechanical devices, and making shaft position readily available to the digital computer. This method is of special interest in mixed systems, i.e., systems where analog servo loops and digital circuits are used together. The disc encoder is a device which generates position-codes directly. The principle is indicated in Figure 3.4. Light and dark areas, representing zeros and ones laid out in a metallized or opaque pattern for reading by electric pick-off brushes or by optical sensors. One brush or photocell for each circular band gives one bit of the code. Figure 3.4(a) indicates how a straight binary weighted code may be obtained. An important practical consideration for this type of encoding may be seen as follows. Assume the disc rotating very slowly past a transition, say from " 0 " to "15". Exactly at the transition all bit sensors must change from 0 to 1. This would require perfect alignment of the sensors, unless some small area of uncertainty should be allowed where some, but not all bits have changed. However, in such an uncertain area, any code might be expected, in other words a reading error of 50% might occur.

12

11

( 7 ) STRAIGHT

BINARY

CODE

(?)

GRAY

CODE

Fig.3.4

Shaft position coding

This highly impractical ambiguity is avoided by using a code such as the Gray code. Figure 3.4(b). The Gray code is one of a class of codes whose main virtue is that one step's variation in the variable to be encoded will cause change in one bit only. Alignment requirement of sensors is thereby only one half step, a meaningful value consistent with the actual coding accuracy. The Gray code runs as follows:

0 1 2 3 4 5 6 7 8 9

0 000 0 00 1 0 0 10 0 0 11 0 10 0 0 10 1 0 110 0 111 10 0 0 10 0 1

0 000 0 00 1 0 0 11 0 0 10 0 110 0 111 0 10 1 0 10 0 110 0 110 1

The number of bits required to obtain a given coding accuracy has not been changed from that of the straight binary code. We have, however, had to pay something to obtain the so-called "unit distance" property: the bits are no longer weighted, i.e., "least and most significant bits have lost their identity, and all bits are equally significant. The most important consequence of this is that normal binary arithmetic rules can not be used. Computing devices therefore will have to convert to straight binary before further processing, or else apply more complicated arithmetic algorithms - whichever is the more attractive from a system's point of view.

36

Disc encoders are available in a variety of sizes, shapes and accuracies, down to the most extreme minuteor even second-of-arc tolerances. In employing devices such as these, a word of caution is in order, however. Although the functional principle is quite straightforward in these devices, certain compromises may have to be made as to their practical operation. One should therefore very carefully consider parameters concerning ruggedness, reliability, power-consumption and -dissipation, environment and sampling rate. In the analog-digital encoding discussed so far, we have assumed a linear quantizing "staircase" such as shown in Figure 3.1. There exist, however, cases, where it is desirable to have the resolution variable over the range. One may, for example, be more interested in fine detail of the small "hiss" than that of the big "bang". One then compresses the high-valued ends of the range into fewer encoding steps, as indicated in Figure 3.5. Similarly, one expands the higher valued ends of the range when decoding. This process, called "companding", is in most prominent use for enhanced transmission economy of voice signals (i.e., "more understandable voice per transmitted bit"). Companding methods may be interesting, wherever data volumes stresses economic aspects of coding methods.

CODING STEPS

VARIABLE BE CODED

TO

Fig.3.5

Companding

3.5 COMPUTER INTERFACING We have now discussed how quantitites of the real physical world can be expressed in digital form such that they may be handled by digital circuits, such as a digital computer. Let us now consider how a "device" is connected to a computer. As mentioned earlier in this chapter, a device may be a data transfer unit of anything from the angle positions of a gimbal suspended gyroscope, to the output of a strain gage, to a guidance command code to be transmitted over a radio link. The computer sees them all as "devices", and is mainly interested in whether they produce or consume data, i.e., are input or output devices; in their data rate, their response time, and the codes and data format which they use. Take as an example a type of device which is connected to many computers: the electric typewriter. We quickly see that this is not one, but two devices: an input keyboard and an output printer. What must the computer do to print a line of text? - Supply the characters, in codes understandable by the printer (see the

37

following section), one by one: letters, punctuations, carriage returns, line feeds all in the right order. The speed in which the codes arrive, is, however, limited by the movement of mechanical parts, and the printer can only accept the next character when the former has been duly recorded. Synchronization information is therefore needed by the computer. Even more accentuated is this need by the keyboard. Many factors determine the rate at which the keys are pressed from contact bounce in switches to operator's skill and "thinking time". Let us first establish certain features common to all devices. To the computer, the outside world is a number of "peripheral devices", Figure 3.6. In some form, the communication to a device may be split up into data, device code or actuating signal, and status or "sync" signal. How general in nature each of these will be depended on the complexity of the entire system, as well as the individual device.

iDATA

DEVICE ACODE__. COMPUTER ^STATUS \ j PERIPHERAL DEVICE

POSSIBLE FURTHER COMMUNICATION

Fig.3.6

Computer communication with outside world

The device code from the computer, activates the device, for example to print the character, whose code is simultaneously presented on the data lines. A "ready" signal is raised by the device whenever it can accept a new data-set (e.g., character) and lowered when it is "busy". Note that this concept is quite general, and applies equally well to input and output devices. The parameters important to the computer are: - Input or output. - Data format and code (word-length, binary, BCD, "ASCII"*, Gray, etc.). Transfer time (how long must data and device code be available for transfer between computer and device). Transfer (how often, max, min, and average, will transfer be required). Let us return for a moment to the printer. The computer puts a character code on the data lines and the "printer" code on the device lines. The printer will accept the character, and lower its "ready" signal. The computer thereby knows it has to wait for the "ready" before it can present the next character. This, however, will take several tens of milliseconds, even for a fast printer, in which time the computer might have done thousands of useful computer operations. It cannot a priori know exactly how many, though. To utilize computer time efficiently, while communicating with peripheral devices at the speed they require is a fundamental problem, to which there exist a number of solutions. We shall discuss the main principles in this section. Note that the speed requirement is normally set by the peripheral device, either for economic reasons ("to keep the printer moving") or for other reasons associated with the system. I.e., a sampling process must be carried out by a clock's precision or an operator command must be obeyed with a minimum response time, etc. The simple solution to let the computer wait is rarely acceptable. The main synchronization methods can be listed as follows in order of rising complexity and data rare capacity. (a) Let the computer wait. (b) Compute for some "safe" maximum time, then wait. (c) Keep computing, but sample the status of the device at intervals, and attend to it whenever it is ready. (d) Keep computing, but let the peripheral device "interrupt" for attention. (e) Let the device communicate directly with the computer memory without direct program control. "American Standard Code for Information Exchange", dominating in use for coding alphanumerical test (letters, digits, punctuation, etc.).

38 Methods ad, with variations, are known as 10-controlled ("In-Out"-) communication with peripheral devices. Method e, is known as "direct memory access" (DMA). 10-control requires the computer to issue a specific "10instruction" such as typically "transfer contents of the accumulator to output device number d". Somehow, there must be a synchronizing mechanism, and that may be done in various ways, e.g., methods ad. Methods a or b would halt the computer temporarily, until the device became ready. Method c would require a variation of the 10-instruction permitting a conditional jump in the computer program depending on the status of the device. Method d requires specific status change signals from peripheral devices to be able to "generate interrupts". An interrupt means that the program, necessarily retaining information which permits the computer to resume where it left off after the interrupt has been attended to. Many variations of interrupts and interrupt handling capabilities are available, and have been a field of much fruitful ingenuity over the years. Note, however, that all of these 10methods, interrupt or not, still defend their place for some application. No method is "perfect" for all applications. Our further discussion will be limited to a few points of special interest. Note that none of the 10-control methods mentioned can ensure perfect efficiency for both computer and 10device in a general case. One or both normally has to waste some of its time. Even a sophisticated interrupt system will be wasteful to some extent. Assume that a compuier has only one 10-device. Data can then be transferred with maximum efficiency. Such a case is, however, rare. Probably there would be at least two devices, say one for input and one for output. We then have the wicked possibility of coinciding interrupts. This problem is easy to deal with. However, the computer must somehow both determine which one of several possible interrupts it has received, and if it receives coinciding interrupts it must be determined which to attend to first. Although coincidence may occur infrequently, the system must always be prepared to handle that situation. In practical systems this uses up part of the computer's capacity, and makes it impossible to guarantee immediate response to all interrupts. In more extreme cases, the computer spends most of its time shifting between interrupt priority levels, thus impairing the efficiency with which it can deal with other tasks. An even more serious problem is the logic implications of multiple interrupts from the programmer's point of view. This problem is dealt with in further depth in another chapter. Direct memory access (DMA) is a good solution in cases, where the data transfer rate is so high that too much computer capacity would be taken away for administration by 10-control. A computer basically consists of (one or more) central computing unit(s) and memory (memories). Instructions and data are stored in memory and fetched from memory via a memory access channel, where a computer word of some given word length, say 16 bits, is transferred, one at a time. A DMA-channel is another subscriber on the memory, which may "steal" memory cycles while the computer is kept waiting. The computer need not "worry", i.e., no logical provision need be made in the program, but its operation will be delayed by the "stolen" memory cycles. The device communicating over a DMA-channel needs to provide a memory address together with its "memory cycle request", and it must provide or accept the data-word, as the case may be input or output. The program will communicate with peripheral devices by finding or placing, respectively the data in "10-tables". This method of communication is of first interest where large amounts of data, i.e., many computer words, are to be transferred. This will then take place as a block transfer, in which the DMA-device has the capability to be started at some table beginning location and to increment addresses for each transferred word up to an ending location of the block or table. The complete block transfer will typically be started (and perhaps be stopped or "signed off) by "conventional" 10-instructions, where the "data" typically specify beginning location and block length, rather than actual data. The DMA-control will then appear as an 10-device. "Ready" and "busy" signal will apply to the complete block transfer. In addition, other status information such as address count, errors, abnormal conditions, etc., will be needed by the administrative programs, and can be sampled while the transfer is in progress. Real time is a parameter, important in many control systems. A clock is then arranged as a peripheral device. E.g., time of day may be read in coded form. The clock may be arranged to generate interrupt at specified times, for example every millisecond. 3.6 DATA TRANSMISSION Data can be transmitted from one place to another over lines or radio channels similarly to voice communications. Direct transmission of analog data has very limited application for a number of reasons. In the more general case, data are transmitted in digital form, which again is modulated upon some carrier. The most interesting fact is, perhaps that it is technically within the state-of-the-art to transmit data at any conceivably demanded rate (say up to a few Gegabits per second), and to make sure of its correctness to any specified degree. The more extreme demands may, of course, rule themselves out for economic reasons if nothing else. In a limited text, such as this, we shall again limit our discussion to the most central and important facts. A data transmission channel has the task to accept binary words of a certain word length and rate at one end, and present them at the other with only a specified amount of loss, error and delay. The necessary functions, some of

39 which are optional, are depicted in Figure 3.7: a stream of words are buffered, may be converted to another code, and transformed to a stream of binary digits occurring at a certain bit rate. These are modulated on to some carrier system which is used on the actual transmission medium, which may typically be lines, radio links or laser beams. For example, the output of the modulator may be a signal confined to the spectral and other requirements standardized for a telephone channel. At the other end the signal is demodulated, etc., by a similar, inverse chain of functional units. Let us look at the functions in some more detail: buffer circuits are necessary to accommodate the power levels and timing requirements of the sending and receiving devices to those of the transmission channel for a parallel word. Various interfaces as well as many parameters are being standardized by several standardizing bodies, such as for example: CCITT, CEPT, ISO, and are used extensively for many standard data transmission tasks. "Recorder" and "decoder", is here a generalized name for the following functions: Adding special bit patterns for "frame sync", necessary to recover the original word pattern in a continuous bit stream. Adapting the bit rate and possible synchronization deficiencies of the transmission channel to the actual rate of incoming and outgoing words. Adding redundancy to the incoming information bits, for detection and correction of errors introduced by noise, etc., in the transmission channel. Encryption. These functions may take on a variety of forms. They may also be included in the sending and receiving devices, rather than the transmission channel. Their purpose is to achieve perfect transmission of data over a nonperfect transmission medium, or more accurately: to obtain a specified maximum error rate in spite of noise and distortion. (Encryption is used for protection of data so that they cannot be understood by unauthorized parties). Speed adaption is required if the transmission channel is built for a specified fixed bit rate higher than that required. Seen from the receiving end, there must be a safe way of identifying each bit as distinct from the previous and the next bit. Further, there must be a safe way of determining which bit is which, so that one can re-edit the bit stream into words. Further, one needs to identify each word, etc. Without going into detail, let us note, that these requirements will take their share of the capacity of the transmission channel. To meet these requirements with satisfactory efficiency, performance and simplicity is and has been the field of much igenious design. Let us note that specified bit rate of transmission has different meaning depending on where in the transmission channel we refer to. A more subtle speed adaption may be required in some transmission systems which apply intermediate storage and/or time division multiplexing: if various parts of the transmission system employs non-synchronized clocks, "slippage" may occur. Circuits can be included which automatically supervise the information stream and eliminates loss of transmitted information by "stuffing". That is: some redundant words are included at regular intervals at the transmitting end. These are removed, or more are inserted along stations of the transmitting path, to ensure that slippage does not cause loss of "paying" information. Some circuits treat data as "messages" of limited, fixed or variable length. In complex nets of many stations, messages are "switched" i.e., routed to their destinations. Sometimes "store and forward" techniques are applied. Error detection and correction may be achieved by special coding. This simplest technique is "parity checking". In each word, an extra bit is included. It is made one or zero depending on the other bits of the word such that the total number of ones in a word is odd ("odd parity";. All received words are checked to see if they have odd parity. If they do not, an error must have occurred in transmission. If the received parity is correct one has some assurance that there were no transmission error. A double error, may, however, go undetected. There is therefore a finite probability of undetected errors. To reduce this probability, one might include more "check-bits". By thus choosing the degree of redundancy and the pattern in which it is employed, any specified probability of undetected errors can be met in a given noise environment. "Cyclic block coding" is a generalized method of high redundancy coding. It is easy to implement, can be applied to any degree of protection, and has well predictable performance if the noise characteristics are known. It is also possible to employ redundant coding to achieve error correction, i.e., transmission errors can be automatically corrected at the receiving end. The simplest concept is perhaps to send each part of the message three times, and determine the correct part of the message three times, and determine the correct part by "majority voting". More sophisticated and efficient methods are also available. Common to all is that they do not give 100% protection, but again: by choosing the degree of redundancy and the pattern in which it is employed, any specified protection may be achieved, in terms of probabilities.

40

DATA IN

BUFFER

RE CODER

SERIALIZER

BIT STREAM

MODULATOR

TRANMITTING SITE

TRANSMISSION MEDIUM

DEMODULATOR

BIT STREAM

SERIAL TO PARALLEL

DECODER ERROR DETECTOR

BUFFER

DATA OUT

RECEIVING SITE

Fig.3.7

Data transmission channel

41 In general, error correction is much more costly redundancy-wise than error detection. An interesting and practical compromise if two way communication is available is error detection, and retransmission of erroneous messages upon demand. It should not be forgotten that many applications will tolerate a certain amount of errors. In any case, the actual need for error free transmission should be properly analyzed before going to an error detection or error correction system. Well established theory is available for proper quantitative design of error protecting systems in data transmission. Similarly the data may be encrypted, that is: special coding and decoding devices may be included to make the information unintelligible to a third party listening in the transmission channel. Standards are especially important in data transmission systems. Many standardizing bodies such as ISO, CCITT, CCIR, CEPT and others have issued standards and recommendations for numerous variables from bit rates, to alphanumeric codes, from time division multiplexing, to modem interfacing. 3.7 THE PROGRAMMERS VIEW Although it is simple in principle to connect a peripheral device to a computer, there are numerous details which must be logically correct and efficiently managed for every information transfer. These details, which fall into the main categories coding, timing, editing and management belong to the more tedious and critical logic problems in computer system design. Some of the problems are common to all devices, but every device has its own special requirements. As a Programmer, one may have written a routine to compute a function and store the results in a table in memory. These numbers can probably best be stored in the format used by the arithmetic unit of the computer. If I want a graphical display of the function and a printed table, the internal table must be converted into two new and diffferent formats: one to suit the digital to analog conversion parts of the graphical display device and one to suit the alphanumeric code used by the printing device. Further, some scaling, editing and possibly some interpolation and some rearrangement of data will be required to make efficient use of the capabilities of the devices and to give the results a neat and easily understandable appearance. Further, it will be useful to also produce some additional information such as axes, "tick marks", and headings. Since the two devices are separate and independent they might be running concurrently, while the central computer at the same time performs these conversion, editing and other functions. To do this, however, some management is necessary. To avoid having to go into every little detail every time, certain of these functions are usually programmed once and for all in such a way that they may be used for various applications. These various programs, termed "device drivers", interrupt handlers", translating and conversion routines, etc., are often combined with other system programs into a common program called the "operating system". Ideally, the system programs of a computer will permit the programmer only to worry about the details which are specific to the task at hand, to let him specify his desires easily, and to allow maximum utilization of the devices which are employed by the system. These problems are discussed in depth in another chapter. Selected Reading for Further Detail General logic, number representations: 1. Richards, R.K. AD- and DA-conversion: 2. Hoeschele, D.F., Jr Analog-to-Digital Digital-to-Analog Conversion Techniques, Wiley 1968. Digital Design, Wiley 1971.

Delta modulation, companding: 3. Belts, J.A. Signal Processing, Modulation and Noise, English Universities' Press, London 1970.

Data transmission, error protection: 4. Martin, J. Teleprocessing Network organization, Prentice-Hall, 1970.

4:

CHAPTER 4 OPTIMIZATION Yngvar Lundh 4.1 THE OPTIMIZATION PROBLEM An avionics computer system, as well as all other engineering jobs, needs optimization. In our case we may somewhat more specifically define the process as: For a given task to seek a device which on one hand solves the problem with adequate performance and reliability, and on the other hand requires minimum space, weight, power and cost in some combination. First let us realize, that this optimization process may be different depending on who does it: the system designer or the computer designer. The entire system's point of view, again may or may not permit complete freedom in sharing the different parts of the jobs between computers, special units, hardware, software and so on. For our discussion let us assume that the solution is not constrained by limited choice of standard sizes, shapes and forms or by choices made by someone else, past history or bad fortune. Although such ideal situations rarely occur, let us still try to seek out the ideal trade-offs in order to come closer to them. One little guide may be deduced already from this little introductory consideration: it is a virtue in itself in this world full of imperfections and compromise, that a complicated system consists of individual, small sub-units which have readily defined functions and connections to their environments, such that they may be replaced, improved and perhaps even removed with minimum effect on the rest of the system. For a computer based system to have adequate performance, will as a minimum mean that all the logic and computational functions required can be done in the time demanded by the system requirements. The designer easily gets into a vicious circle here, because he does not necessarily know all the logic and arithmetic functions required until he has the bulk of the design work already done. But long before then he must have assumed or made a number of choices. These may later prove to be far from optimal. For example, if the choice were between computers A and B, he may have to actually program many functions before he knows if the computing capacity is adequate or grossly over-estimated. To have a too large computer sitting idle during much of its time rarely improves the system in any way, but may be a burden. Clearly, therefore methods for making the right choice early are in demand. It will always be necessary to break a complicated system down into smaller parts for various purposes. Each part, then can be defined and specified, and be optimized individually during the design process. As more details become clear during this process, conflicts may arise because of unforeseen details, and there will be choices to be made which involve more than one part. Often these choices are such that simplification of one part means complication of another. During development one has a dynamic situation, some decisions are easy to change later, some are difficult. Since often various parts are to be made by different groups of people, companies or establishments, contractual and various, perhaps irrational viewpoints often tend to remove further optimization from the strictly technical level. This can easily lead to a sub-optimal solution, and it may be regarded as part of good system planning to be aware of this feature of the practical world and to seek the solutions which are the least prone to non-technical optimization. Without trying to offer further general guidelines, let us be allowed to offer some pieces of experience which have proved useful. Partitioning of the system is extremely important. It is more important that the interfaces between parts are simple, functionally logical, well definable and well defined than that the total sum of all parts are an absolute minimum. We are here referring to the partitioning done on an early planning stage of a system being developed. Design jobs to be done by people are highly dependent not only on their competence but also on their motivation. It is, therefore definitely contributing to a good solution if partitioning both of system functions and of development jobs to be done can be made with this in mind. The best criterion for this is often the partitioning which minimizes the need for communication between people (not the communication, but the need for it). Among other things, this implies that the size of each task be such that it can be managed by one man who is master of all the problems on this level, and who may safely refer problems on other levels to other people.

43

Let us not go further into management considerations, but only note that various decisions on the technical level can not be seen isolated from how the detailed development of technical solutions are to be undertaken, if a really optimal solution is to be expected in the end. 4.2 IMPORTANT PARAMETERS Let us turn now to some specific important parameters which are useful to identify and consider in optimization of a computer based system. Logic speed is a "technological factor", which characterizes logic circuits. It is measured in maximum ("clock") rate at which one can accept pulses, for example to be counted. One for example talks of "30 MHz-logic". Another useful measure is logic stage delay, i.e., the time from the input signals are presented to a single gate circuit until the gate produces its final output. Typical value is several nanoseconds. Computing speed is a very important factor, which unfortunately is difficult to measure exactly. It will have different meaning depending on the computer. One measure is the number of machine instructions which can be executed per second, or the instruction rate. However, execution time is normally different for different instructions. An average may be used, but this approximation is application dependent. Machine instructions are also, of course, different from one machine to another - some do more useful work per instruction than others. It is therefore almost impossible, and inconsistent with the continuous movement in the state of the art, to define a universal measure of computing speed. After considering these factors instruction rate and instruction power (of which word length is one, very coarse, indication), the next thing to do, is to actually program some typical, preferably frequently occurring functions, and find out what the computation time is. One function frequently used for comparison is the computation time for calculating the square root of a number. Other functions may, of course, be more relevant for specific applications. Memory capacity is another important factor, which is easier to characterize and measure. The principal parameters are Size; N words of B bits each. Access time; time from the address is specified until the desired word content is produced for read operations. Cycle time; minimum time taken per successive operation. Note that (access time) < (cycle time) These times may be different for read and write operations. "Random access" means "access time is independent of the address and the order in which addresses are called". Certain memory types are serial in some way, which mean that the access time is much shorter when the words are accessed one by one in a given order. If an arbitrary word is sought, one has to wait for an arbitrary part of a "multicylce" or "revolution". This is referred to as non-random access type of organization. The access time for such memories is a function of several variables and of the way in which the memory is used, rather than a single figure. Since speed is desirable, but hard to come by, larger memory systems normally consist of a combination of fast and slow memory. Some mass memories are often arranged to be able to transfer large blocks of many words rather than single words. Volatility is another quality of importance for many applications: the danger of losing memory content in the case of power failure or abnormal conditions. A continuum of properties are available in different types of memory such as: "completely volatile", "power protected", "read mostly", "programmable read only", "read only", etc. Communication capacity is the efficiency with which the computer can exchange data with peripheral devices, that is data transfer rate, flexibility of synchronization (direct memory access, interrupt, etc.) and adaptability to various situations and equipment configurations. This concerns both hardware and software facilities. Survivability and reliability under normal and adverse conditions are important parameters. Many avionics systems are required to operate, perhaps at reduced performance, with defective parts. This, of course, then is a requirement of fundamental importance to the system design, specification and evaluation.

44 Modularity, i.e., partitioning into replaceable parts, is normally a desirable quality. Physical parameters of primary importance are: volume, weight, power dissipation. In addition numerous parameters associated with environmental resistivity are important, such as operating temperature range, vibration and shock, electrical noise, radiation, etc. Programming complexity is a feature of the utmost importance for computer systems in general. For an avionics system, the computer programs, even all "application programs" must be considered to be part of the system. When a system is complete and working, one might therefore consider it immaterial how much trouble went into completing the programs. However, programs as well as hardware normally need maintenance. Change in data characteristics during use may reveal shortcomings or errors. Accommodating additional facilities into the system, expansions and improvements, all require the programs to be re-examined and changed. The complete program must therefore not be a mysterious, unreadable tape or jungle of symbols. It should be specified, described, explained and broken down into functional parts at least as thoroughly as the hardware parts of the system. Further, there should be available facilities for making changes. This means that new or changed programs can be written and tested using the same methods (language, editing, testing) as those used orginally. These are the main parameters which characterize a computer based system. Unfortunately, most of them are difficult to measure. This fact may often place too much weight on the few quantities which can be measured, overlooking other important factors, and thereby missing better solutions. Were it not for this unfortunate situation, optimization would be more straightforward, certain and less of an art. A comprehensive study of a number of important and representative computers have been made by C.G.Bell and A.Newell in a voluminous book: "Computer Structures: Readings and Examples" (McGraw-Hill 1971). They have introduced unified methods for describing the computer organization and instruction coding, and they have identified sets of "parameters" or "dimensions": which are all important for characterizing computers. All these dimensions can then he said to form a large "computer space". They define the main dimensions of this space to be: Logic technology (tubes, transistors, IC's, . . .), Word size (number of bits), Addresses per instruction, Structure (organization and interconnection of main functional units), Memory access (random, cyclic, linear, . . . ), Memory concurrency (multiprogramming, interrupt handling, . . .), Processor concurrency (parallel, serial, multiple instruction streams, . . .). The complexity and large amount of information collected in that book throws much needed light on many sides of computer technology and how to appreciate computers. It also, however, serves to illustrate the fact that there is no really simple and universal way to describe and compare all aspects of computers. 4.3 TYPICAL TRADE-OFF SITUATIONS In this section we shall identify some important trade-offs which are useful to know when seeking a way out of the multitude of possible configurations which a computer based system may be given. Speed complexity are related in a clear cut and often surprisingly general way. Let us look at two examples: (1) To perform 200 000 additions per second we can use one adder which can do its job in 5 microseconds. If such an adder were not available, or had an unattractive price, we might consider a slower one, say a 10 microsecond unit. Almost certainly we could replace the fast one by two slow ones plus some extra circuitry to distribute the load between them. (2) If a binary full adder needs 10 nanoseconds to add two bits and 5 ns to propagate the carry, a 16 bit parallel adder would consist of 16 such circuits and might require 10 + 5.16 = 90 nanoseconds for adding two 16 bit numbers, plus perhaps another 20 nanoseconds to set the result into a flip-flop register. If we, however, did not require this high speed, we could do the job bit by bit, i.e., in series instead of parallel. Using the same full adder circuit, we would only require one instead of sixteen. Instead of 110 ns, the total add time might be (10 + 5 + 20) ns per bit, i.e., 35.16 = 560 ns for 16 bits. These, slightly simplified, examples are typical of the general rule that speed may be traded for simplicity: A faster unit can be simpler or a more complex unit can be slower to achieve a specified processing capacity. Instruction repertoire - speed is just a specific example of the same rule. Let us look at another example. Computer A (big) has a multiply-instruction in its repertoire, computer B (small) has not. B has a standard

45

subroutine, however, which employs B's simple instructions such as add and shift to do the same job. The interesting thing now is "how long does multiplication take", not "which one has hardware multiply" or "what is the instruction rate" Instructions - speed - memory size are really three factors which determine computing capacity separately and can be traded against each other. To compute a sine function one can for example (a) have an instruction to produce it directly, by a complicated arithmetic unit; or (b) do a subroutine using simpler instructions, more time (assuming the same logic speed in the arithmetic unit) and more memory; or (c) do a table look-up, using extremely simple, if any arithmetic, very little time and a large amount of memory. Accuracy - word length is, of course, unlimited in a digital computer. However, if one needs more than 16 bit accuracy in a 16-bit machine, one needs to program multiple word length operations. This takes much more than twice the time for double precision than for single, etc. That is probably still the most economical if the need arises infrequently. If, on the other hand, higher precision is in frequent demand, a longer word length may be a cheaper alternative than a higher instruction rate. All these factors are interrelated and dependent in ways which are difficult to describe in a general, application independent way. The most important fact is, however, that they are interdependent. It is for example meaningless (or at best a very coarse approximation) to say that slow processes need slow computers, meaning low instruction rate. It is the total processing capacity which must be matched to the task. Another matter is that there usually are constraints which limit the free choice along the entire scale of tach parameter. In real time systems, this may be illustrated by the two factors throughput and response time. "Real time data processing" in general means that: Any backlog of data accumulated in the processor never increases beyond a given maximum value for a specified data throughput which may be maintained indefinitely. Response time is: the time taken for a data value entering the data process to influence the output. The required response time may require a fast computer rather than a slow but complicated one. For example, our previous suggestion with the two 10-microsecond adders would be unacceptable if the result were needed in 50 microseconds (i.e., the delay of 10 us could not be tolerated). So although the two adders might cope with the throughput, the choice then would be constrained by the response time requirement. Hardware-software is another trade-off, which really is a different name for the instruction-speed-memory size, which was already mentioned. This name, however, can also refer to the trade-off between built in functions and functions which must be reconsidered when programming a new situation. A Fourier transform, may be done by a special function unit (hardware) or a special subroutine (software). Similarly a computer may have an interrupt handling subroutine (sofware), or much of the logic such as priority, save-unsave, etc., may be implemented by special devices (hardware). Such functions may be solved equally well by hardware or software. In a computer offered as a component there are, however, great variations in which and how many such standard functions have been included at all, or must be done by the system designer and application programmer. This trade-off may not be important for the performance, but to flexibility and design changes, as well as complexity of the system design job. Reliability-complexity is a less well defined relationship. With a given technology, i.e., type of circuit components and tolerances, the simplest, i.e., smallest number of components will be the most reliable if the organization is non-redundant. If the reliability of the computer thus obtained is too small (mean time between failures too short), it could be improved by duplicating the computer, i.e., to have another doing the same job, and some equipment or programs to decide if one computer fails and then disconnect it. Even more reliability both per dollar and per liter, etc., and totally, may be achieved using other, more sophisticated redundancy methods. Theory and methods for design of fault tolerant computers are in constant development. Conceptually, however, they tend to be difficult. They are therefore expensive, and normally not justified on a limited economic basis. The economic aspects of reliability are normally covered by conservative use of tolerances and well proven technological methods. There are, however, many cases especially in avionics systems, where this is used to its fullest extent, and still is insufficient. Extreme statistical reliability is for example required during missions of long duration without possibility of repair. Special techniques and quantitative methods for assuring necessary reliability must then be employed. In other cases hazards may occur against which it would be impossible to make the system resistant. This is true with many military systems, and equipment which is to operate in less well known environments. "Graceful degradation" is then desirable. The system may be designed to operate for example in emergency modes perhaps at reduced performance when parts have been disabled. The trade-off here is between survivability and complexity.

46 Another type of trade-off in a highly dynamic field such as ours concerns credibility of new and exotic devices. Our aim is at new systems to be developed rather than at old proven ones. However, we normally want new ideas implemented early to beat "the competition" in some form or another. It is therefore of interest to consider which solution can be implemented first. In an existing system it is frequently easy to point out not only shortcomings, but how things ought to have been. In the new system to be developed, however, we are typically "going to employ some extremely attractive new techniques" which completely eliminate the old shortcomings. To foresee the inevitable new shortcomings of the new system is desirable, but not automatic. Good system partitioning has already been mentiond, and may more specifically more easily permit correction of mistakes along the way. It is also no coincidence that small computers are normally earlier to utilize new technological progress than big ones: they take shorter time to develop. Therefore, they are often competitive in computations per dollar or per liter although the small computer would tend to loose against the big one using the same technology. Concepts which can be implemented rapidly, therefore have a virtue by themselves. For tasks other than theoretical: An old-fashioned and primitive, but working device is infinitely more efficient and useful than a modem sophisticated one which only exists in theory. 4.4 METHODS OF DETERMINING ADEQUACY The only method which can be recommeded, other than actually trying out a complete system is simulation. A computer based system consists of computers) and peripheral devices. The latter must be specified by their performance data and the job they are to do. The computer is to be designed, chosen and/or programmed. After this has been done, most of the work is finished. It is of great interest to be able to make estimates long before then. No general way to achieve this can be offered. Let us, however, describe one attractive way of designing dedicated computer based systems, and leave it to the reader how he might make use of it in this case. We are to have a computer doing a specified job as part of an avionics system. We will then first assume a computer X. We will then know its instruction repertoire, possible standard subroutines, 10-functions, etc., and how long each takes to execute. First we write a simulator for the new computer as a programme on another computer S (preferably in a high level language, which may even be computer independent). We then write the application programs for the assumed computer X. Further, we write a monitor program to be run on computer S, simulating whatever is required of the environment, and monitoring the (simulated) performance of X. It runs the X-computer simulator program and keeps account of how long each "operation" takens and how often it is performed. "Operation" may refer to machine instruction, subroutine calls, times through specific program loops, etc. We may thus simulate our whole problem, or critical parts of it using computer S only, not even needing to acquire computer X. This procedure allows us to do the following important investigations. We may make sure that processing capacity is adequate. For a real time system that typically means that the time available, e.g., within a sampling interval is sufficient for running through all necessary program loops by way of all possible paths. Similarly we will find out if the processing capacity is grossly oversized. We can in other words, determine how the computer meets the demand for processing capacity. We may investigate alternate programming methods, algorithms concerning their consumption of computer capacity as well as their performance. We may identify the most critical parts of the computer limiting its capacity for our application. This is done by examining the accounts of the monitor for which instructions or operations are most frequently used and how time is spent. This is especially useful both in seeking and evaluating alternate algorithms as well as studying the value of optional features. The method is equally useful for considering a computer to be bought or an entirely new one to be developed. These procedures may further be applied not only in determining the adequacy of computer X, but in comparing computer X, Y, Z while seeking the optimum solution. The facilities offered by a simulation such as this are in many respects greater from the point of view of optimization than it would be to actually have computers X, Y and Z available, since computer S is simultaneously used for obtaining all these useful statistics. It is also generally a fast method because it eliminates many non-essential experimental difficulties. The application programs which where thus used during simulation are immediately ready to be used in the actual computer later on. To simulate the entire system may be useful. Without going to that extreme, however, it may still relieve the systems designer of many uncertainties if he can only identify and simulate the more critical points at an early stage. This both enables him to make better estimates, and forces him at an early stage to actively pursue the critical points, which in general is good design practice.

47

CHAPTER 5 SYSTEMS AND SYSTEM DESIGN (Software Design in Computer Based Systems) C.S.E. Phillips 5.1 INTRODUCTION This chapter is not concerned with the writing of programs by individuals for their own purposes, nor with computation per se. It is concerned with the production of software by professional teams for computer controlled systems dedicated to some special purpose. Such systems are essentially software based, usually real time and, as is now realized, much more complex than they may appear to the outsider. Recent experience has shown that these systems have taken much longer to produce and have been less successful in operation than had been expected at the time of their conception. In particular, the amount of software needed and the difficulty of its production has been severely underestimated. This was mainly due to the assumption that the individualistic, problem solving approach appropriate to programmers as computer users is adequate for system building; in other words, the lack of systems thinking and a systems approach. 5.2 SYSTEMS A system is best defined as a whole consisting of a set of interacting constituents, where the whole is different from or transcends the sum of the constituents. This definition is so all-embracing that it is not surprising the subject should carry a high flown subjective air and be regarded at times as of little practical use. In modem times the systems viewpoint has permeated organization theory (the interacting parts being men), but if we think of the organizational problems faced by the builders of the Pyramids the study of systems could be said to predate science. Nevertheless, the real impact of systems thinking has come quite recently, in sociology, politics, economics, management, etc., as well as in most branches of science and engineering. There are natural systems (physical and biological), man-made systems (political, economic, engineering), designed systems (avionic, computer, social Utopian), slowly evolving systems (political, economic), systems which are self regulatory, controllable, goal-seeking, adaptive, learning, growing, decaying, etc, and those which are not There is a small but growing interest in the study of systems concepts in general both for its intrinsic interest and for its practical importance as the basis for system design. In computer based systems particularly, system problems are beginning to overshadow the problems of engineering technique. In the past most systems have been regarded as "closed" i.e., having no inputs from or outputs to an environment. Such systems, for example the planetary system, systems of mathematics and physics, nineteenth century economic models, etc., can be recognized by their lack of purpose (any purpose other than their own existence) and are conventionally subjects of scientific or engineering work. The interactions between the constituents and the internal behavior of a closed system can be expressed often mathematically in great detail as casual relationships. Physical scientists and engineers are trained in and are mostly interested in closed systems. Thus scientists analyze natural systems whose purpose is not their concern, whilst engineers tend to pay only lip service to purpose since they are primarily concerned with making things. White and Tauber1 in their book Systems Analysis are mainly concerned with closed systems and trace their extensive and highly successful development from the Renaissance onwards. An open system has an environment and it was biologists who first pointed out that their systems affected and were affected by the environment3. Open systems which are characterized by "purpose" and "hierarchy" are never an end in themselves and require Ideological (goal directed) rather than causal explanations. For example, in answer to the question why does the apple fall to the ground? we may see this episode as belonging to a closed gravitational system and reply because the weight exceeded the strength of the stalk. If the gravitational system is regarded as a sub-system of an ecological system we answer so as to produce more trees. We have only to think of "man in his environment", the topical interest in world social and ecological matters, the falling interest in "science" (i.e., regarded as closed system thinking), modern attitudes to organizational and planning techniques and finally the very recent attitude towards computers (that they are rarely an end in themselves) to realize how widespread open system thinking has become. In fact the term system is now synonymous with open system.

48

Systems whose interacting parts are themselves systems are by definition hierarchical - thus we speak of subsystems and sub-sub-systems and the purpose of a sub-system is to perform some function for the system (which itself may be part of a super-system). For a very crude example, in the following connected, "bottom-up" sequence of system levels solid state physics, microcircuits, computer architecture, software, navigation system, aircraft, air defence, economics, foreign policy, national politics, world objectives, each can be regarded as an open system which makes use of and depends on the (previous) sub-system and whose purpose is to serve and thus affect the behavior of the (successive) super-system. Turning to the class of man-made systems (more precisely, sub-systems) which can be designed or re-designed over a short time period, that is those which primarily concern engineers and computer scientists, one might reasonably conclude from this that the design of a new system would take other levels into account. Here we reveal a major system design problem. Difficult as it sometimes is for a designer to cooperate with designers of other sub-systems at the same level, cooperation between designers at different levels is often poor or even negative. The reasons for this are partly psychological (individualistic attitudes, etc.) and partly mutual incomprehension (different disciplines). It is difficult for designers to give and take responsibility for the design of even the immediate system level above and below without creating difficult problems of cooperation. More important, perhaps, there is a further inherent difficulty with the design of an open system which arises from the fact that it is defined Ideologically. It seems to be a general characteristic of open systems that, though they clearly have a purpose of some kind, on careful examination that purpose is revealed as uncertain or ambiguous and that the difficulty of developing a new system is more connected with this ambiguity and uncertainty of purpose than from its inherent complexity. This may account for the fact that it seems to be easier to put two men on the moon than to develop an air traffic control system or reorganize a local authority. The ambiguity is often unrecognized in that the "purpose" may be multiple (i.e., a "balanced" set of objectives), understood differently with different people, or changing with time. Furthermore the purpose of a system can only be described in terms of a system at a higher hierarchic level. As Langefors7 has said, all systems are potentially sub-systems. But what is the purpose of this higher level system? Here we touch on a paradox, that a system to be developed can be fully understood only in terms of (theoretically) all higher levels of system imaginable; yet work can start only if the purpose of the system is taken for granted, (e.g., two men on the moon). Unfortunately it is all too easy to conceptually dose a system, that is, to assume its purpose is self evident; the problem in practice is to open it up again. The solution of this problem of iteration between hierarchic levels belongs to the realm of system design methodology.

5.3 SYSTEM DESIGN METHODOLOGY Recent experience9 in the design of complex computer-based systems has shown that such systems have taken much longer to produce and have been less successful in operation than had been expected at the time of their conception. In particular the amount of software needed has been severely underestimated. A more general understanding of Systems and Systems thinking would have avoided such errors and disappointments. On the other hand it must be admitted that at present the study of systems concepts offers wisdom and understanding rather than panaceas for the design of complex systems. Nevertheless there is a growing interest in the application of these concepts and theories to system design methodology. Here we must point out the important difference both between systems and engineering and between individual and team work. In terms of man-years, the most efficient way of developing for example a hardware or software system is for the engineer or programmer to "close" it (i.e., to define its operational purpose himself), to develop it where possible from standard available sub-systems, and to design and construct it himself. He would evolve his own instinctive ad hoc methodology, using such principles as seemed appropriate, based on his experience and ability. Where an organization (system of interacting men) is concerned, such an approach is not possible as its "intelligence" is of relatively low order. It is generally agreed that the rate of development is not proportionately increased when larger teams are used. We must recognize that computer-based real time systems are particularly complex because of the software involved. It is not that the elemental sub-programs are any more complex than the other parts of the system such as the sensors and other peripheral units; nor is it connected with the computing hardware, which can often be regarded as a given "off-the-shelf sub-system of the software. The problem arises partly because of the lack of standardized sub-programs and any standard way of defining and interconnecting them. It is for this reason that individual programming work is so much more productive than team work. Another problem is the communication between programmers and higher level system designers as already mentioned. It is unlikely that programmers would be capable of, or even be permitted to, dominate and determine the design of, for example, an avionic computer system. For the future, one must assume that avionics system designers will have a much better training in computer science. What methods should we use to develop computer-based real time systems? Boguslaw4, in an amusing analogy between the design of social Utopias and computer-based systems, has proposed four main system design ideologies. Firstly, formal methods in which the proposed system is planned and defined in exhaustive detail, secondly,

49

heuristic methods using "good" (but vague) principles, thirdly the use of available (standard) sub-systems and fourthly, the "ad hoc" or unplanned approach. Clearly, the last method has been well tried, will always be popular and, let us admit it, more interesting for the individual designer. One formal method under investigation at the moment attempts to borrow the Syntax directed techniques of compiler writers by defining systems in syntactic terms11-12. Unfortunately, formal methods tend to be over-rigid and obscure in practice. As far as general principles are concerned, those currently in favor are the "top down" (in which the details are considered first) and the principle of iteration. A particular methodology of software development combines these principles with the idea of organized evaluation - the "three prototype method"10. Here a system would "evolve" by being developed three times (rather than once), the first time to clarify its "purpose", the second to find out how to make it and the third time, how to make an engineered product. The philosophy behind this idea is that iteration between hierarchic levels is impracticable during the development of a software system, so that definite time slots are arranged for this purpose between the development of three essentially closed systems. A research modelling or prefeasibility stage might also be required before work on the first prototype was begun. The "available sub units" approach is much used in traditional engineering. In computing systems the method is exemplified by the idea of computer packages in which standard programs of sets of programs are used. Such packages are beginning to be used in A.D.P. systems where standard operations occur, but not yet for real-time systems. Many project managers seem unaware that a new program is not made like hardware, but must be invented before it can be produced. The software should therefore be their first concern - not something to be left till later. It is difficult to draw any definite conclusions about the trend in system design methodology. The subject is very complex, embracing on the one hand project management (another system in itself) and organization theory and on the other, systems of documentation (another difficult and neglected subject). With a very small, high calibre team, ad hoc methods may still be best, but it is more usual now to evolve more formal, if arbitrary, methods. In general, the principle of iteration is thought to be particularly important, i.e., cycling through "top-down" to "bottom-up", but it is difficult to achieve this in practice where the teams are large. Undoubtedly, better methods of controlling iterative system development using computer aided documentation of the time varying managerial, design and programming data will be introduced in the future, but human problems will be more resistant to change. System designers largely concern themselves with their own problems and often tend to regard "subsystem desigems" on the one hand as short-sighted and incompetent and "super-system designers" on the other as ignorant and vacillatory. This problem is not necessarily alleviated when there is a one to one correspondence between system levels and an organizational hierarchy. We are mainly concerned in computer based systems with iterations between levels confined to closely allied sdentific and technical disciplines. As far as broader matters such as defence systems as a whole are concerned the problem is even more difficult. Present administrative and managerial methods have been developed for the procurement of "equipment" i.e., well-defined, "closed" systems, so that inter-disciplinary iterations over many levels involving "ultimate" users would require a revolutionary change in attitudes. This problem is better understood in the social sdences than in computing or engineering. 5.4 PROGRAMS AS SYSTEMS Let us imagine that we are given the task of writing a real time program given suitable hardware and programming facilities including a good, high level language. Taking a systems viewpoint we know that we ought to interact at least one level up and down. The level down involves taking part in the design or choice of the programming language and the computer configuration. Let us ignore this aspect by assuming that previous experience has confirmed our agreement with the choice. The level up concerns operational descriptions which we take part in, similarly we idealistically expect that operation (e.g., avionic system) designers help to write the program. As a result of this cooperation, iterations of analysis and synthesis can take place which will result in an expanded and modified operational description and a first attempt at a written program. We note immediately that the typical designer of an operational avionics system has little experience of real time programming. The typical computer programmer probably knows little about avionics. How are they to communicate with each other? This is an example of the interdisciplinary problem already mentiond. Moreover, it is a fact that the higher the hierarchic system level the less precise and "scientific" the subject matter becomes. It is fair to say that there is as yet no organized and agreed body of knowledge about the specification and the writing of such programs. It would be helpful therefore if we could interpose additional conceptual system levels between the application designer and the program writer. There appears to be two possible levels where more formal techniques can be introduced, the functional specification and its translation into networks of process and data areas. The first of these levels concerns problems of system specification and "man-machine interaction". There is a need here for a technique which clearly, rigorously and unambiguously describes the user requirements of the

50 system as far as possible in hierarchic terms. Working from these descriptions a program designer would be then able to draw up a high level program design in which all the main data areas, programs and their interactions are specified. The aim should be to provide a time ordered description of all the operations undertaken by both man and machine for each of the functions undertaken by the system. The description would make clear all branches in a chain of operations and also those places where parallel operations occur. The object would be to enforce a structured description of the system which is more precise than plain English and which is, in principle at least, hardware independent. There are two main techniques which offer possibilities. One is to "program" each function in plain English, with an accompanying flow chart. Each "program" would contain operations to be performed manually as well by the computer. In one scheme of this type10, modifications to conventional flow charts have been made to indicate parallel operations and to distinguish conditional branches occurring within the computer from those occurring manually. It would be possible to simulate such a "program" so as to investigate the proposed system from a functional point of view. A more "mathematical" technique is to describe the system syntactically10'11'12. This method is essentially hierarchical in that each definition is expanded into sub-definitions and is inspired by the methods of defining and constructing computer languages. It goes beyond a textual description of the operational-requirement in that it "holds the hope of being a more rigorous way of developing real-time programs". However there is some doubt whether such a rigid technique will be suitable for the rather diffuse, parallel running functions which must be expressed at this sytem level or whether operational system designers will be able to master such a sophisticated technique. When those parts of the functional description which must be performed by the computer are separately defined, the conversion of these into running computer programs has still to be accomplished. At this lower level it is preferable to think in broader terms than either detailed programming (coding) or computing hardware. The program network10 is one possible technique. It is based on the concept that the functions are performed by a set of parallel-running, cooperating processes whose interactions consist of data transfer. A process is defined as a more or less continuous conversion of data from one form to another. At this stage we are not concerned with the means by which such a conversion is to be achieved so that a process is best thought of as a "virtual computer" or a program to be written. The particular system concept of dividing real time programs into processes and data areas and the diagrammatic technique described below which arises from it is not universally used, but is gaining acceptance, primarily because it is an easy method of specifying and comprehending computer programs. Diagrammatic techniques which illustrate the continuous running of sub-programs in parallel are analagous to the block diagrams of electronic engineering or analog computing. The importance of such diagrams, which should not be confused with flow diagrams, has been recognized only slowly partly because, as mentioned previously, programs have been regarded as algorithms rather than systems and partly because there is no agreed basic philosophy of real time computing. Having described how the functions of the system can be achieved by means of interacting conceptual processes, we now need to consider in turn how these processes should be constructed. Let us assume we have drawn up a network of processes which is connected with a manual and physical environment by means of data and signal transfer. Our remaining problem is therefore twofold: to write a program which will run on a machine for each process and to provide a means of activating processes. One of the major conceptual and practical difficulties in computing arises from the fact that these process programs must share common computing hardware, which allows only one process, or part of a process, to run at a time. Of course, multi-computer systems exist which share the work crudely but it would be impractical and inefficient to use a computer for each process. Similarly one could envisage multi-processor systems where particular processes are allocated to "processors", but the present trend toward "reconfigurable" multi-processors for higher reliability implies no such allocative distinction. We therefore arrive at a situation where the processes are to be implemented using a common set of hardware, the computer; they share access to a data base containing current information about the environment, and in some situations share code to perform their actions. Thus, detailed knowledge of the interfaces, both in terms of messages passing between processes and also via shared data base areas together with information about shared code is vital to specifying the program design. Such information can be conveyed by means of a matrix of interconnections or more conveniently by the network diagram. Such a network of processes does not include those manual and nonmanual processes external to the computer, but in early development it is good practice to add these in order to describe and simulate the total system. An individual process is "constructed" by writing a program. A process algorithm is therefore described in plain English or at a more detailed level by its program text or alternatively by a mixture of the two. A single activation of a process is called a "task". We are now concerned with two questions, how to control these tasks and how to write the programs. Owing to hardware limitations, tasks must run sequentially and must share

51 hardware resources with all other tasks. This problem is overcome by developing a separate programming system called the "real time operating system", which conceptually creates from the (usually single) processor of the computer many virtual processors to run processes. The real time software system can therefore be divided into two main sub-systems, one concerned with the application tasks to be carried out and the other with the means by which tasks are scheduled, and allocated to computing resources such as stores, computing time and peripheral equipment. Leaving the application programs aside for the moment, we have seen that the real time operating system, which is often rather confusingly described as "system software" or even "software", transforms the computing machine into a "virtual machine". (In the future one can expect computer designers to respond to this reflection on their equipment by designing hardware more closely matched to programmers requirements, once these are better understood.) A real time operating system does not normally interact with ordinary "user" programmers, as in a conventional computing installation. It is therefore simpler in this sense than the large multi-purpose conventional operating systems. (The adjectives "multi-purpose" and "general purpose" when applied to the word "system" should cause alarm and it is interesting to observe that the complexity of conventional operating systems is widely believed to be out of proportion to the benefits they bring.) A real time operating system has more limited objectives, but even here there is a need for a better conceptual understanding and an underlying philosophy. The idea of attaining a more modular and extensible system (i.e., by dividing into sub-systems) is gaining ground, but the "ad hoc" approach still dominates. The main difficulty is one of definition. For example a recent trend is to regard a real time operating system as consisting of primitive routines called a "kernel" or "nucleus" handling operating system tasks and application tasks indistinguishably. This latter view point presupposes a more clearly defined concept of a task and a particular philosophy of real time programming. It should be emphasized that it is often difficult to differentiate between the actual tasks to be performed and such matters as the interactions between tasks, avoiding, detecting and controlling fault situations, arranging for easy alterations off and, perhaps, on line, avoiding "deadly embraces" (where two tasks prevent each other from using resources) and, in a message based system, "back up" where local overload spreads to all message channels. Whether or not the time-shared processes include operating system programs which look like application programs, that is irrespective of the theory behind the division into the two sub-systems, each sub-system requires the construction of processes, i.e., the writing of programs. It is possible at this stage to regard this work as an independent activity, i.e., merely a case of developing an algorithm to a specification. However these processes are often complicated or ill defined and the corresponding programs when written reveal inadequacies in the upper level design. It is a valuable conception therefore to sub-divide each process into sub-processes and data areas in exactly the same way and for exactly the same reason as the system was divided into processes. The difference here is that sub-process and data area interconnections involve the data structures and sub-routine calls of the programming language used. In the case of an Algol type of language such as Coral 66, Reference 13, sub-processes can be described by procedures, and data area connections are defined and restricted by the syntax. A process can therefore be envisaged as continuing private data indistinguishable at that level of description from pure program, which at a level below is revealed as the linkage between sub-processes. It is an obvious extension upwards for a language to include within its syntax, built-in ways of handling parallel process inter-communication as well. The exact requirements for such an invasion of operating system functions is not well understood as yet so that such language must be regarded as experimental. Having sub-divided processes hierarchically in this manner we arrive at elemental processes which are programmed preferably as procedures in high level language (or sub-routines in assembly code). These lowest level procedures will probably be relatively simple, communicating with data either directly or via the parameter mechanism provided by the language. The extent to which procedures can be nested depends on the language used. Some procedures will be common so that a diagram will show a hierarchical network of procedures rather than a simple tree. Connections with data will be complex so that it may well prove useful to store network information on a central computing facility as part of the documentation system - together with program text. The efficiency of the running programs depends on the language design in relation to the computer architecture and the quality of the compiler. A small number of particularly fundamental pieces of program may be written as "macros" which expand into short pieces of machine code. Viewing real time programs as systems, these macros are technically the lowest level elements. However in a modem (high level language) computer based system the "procedure" should be regarded as the fundamental element which drives the system. The computer based system is then more accurately described as a software based system, since translation of software into hardware actions is purely automatic.

5.5 FUNCTIONAL SYSTEM APPROACH We have referred to the need for a technique which bridges the gap between the functional description of the software sub-system and the complex detailing of programs which are ultimately the means by which these functions are achieved. What is really required for the software is a number of parallel continually running data processing operations, but we are forced by the inherent nature of digital computers to construct each data processing operation

52 in terms of an ordered sequence of steps - as the word "program" implies. We are also forced to simulate the parallel running of these operations by time sharing computer hardware. We are not therefore concerned in what follows with programs as such as algorithms expressed in programming language or flow diagrams since these are the details of construction of a process. We are attacking the main problem in software production - deciding what programs are to be written. The actual writing of a program is usually a relatively straightforward job. The principle behind the particular method to be outlined is that the software is regarded as a system whose constituents are (1) data; and (2) processes and where the interactions between constituents are (1) reading and writing of data by processes; and (2) interactions between processes. The interactions between processes at an upper system level are (1) interrupts, (2) system calls (interactions with some form of real time operating system),aand (3) sequential activations. The system is hierarchical in the sense that processes contain (or in programming terminology "call") sub-processes, leading to (4) hierarchical interactions between processes. Although these entities and relationships can be set down in matrix form, a diagram is a more useful tool for this purpose, and such diagrams are referred to as "program networks" or "Phillips diagrams". 5.6 PURPOSE OF PROGRAMMING NETWORK DIAGRAMS The programming network 24 ' 27 is a two-dimensional, diagrammatic, information processing, language primarily intended to simplify the description of large programs particularly those to be written by a number of programmers (although it can be used to describe any program). The most important time to draw up programming networks is at the systems analysis stage, i.e., after the system requirements have been clearly established, (by means of functional specifications for example). Program networks are useful for: (1) (2) (3) (4) (5) (6) (7) (8) Program design, Program interfacing and integration, Assisting management in understanding, Monitoring progress, Easing program and modification and maintenance, Instructing new recruits, Documentation Program size and time estimation.

Data and Processes The programming network consists essentially of two entities, data (represented by rectangles and processes (represented by circles) together with lines which show intercommunication between these two entities. The reading of data by processes and the writing of data into data areas by processes is represented by simple unbroken lines. The distinction between data input by a process or data output from a process is indicated by arrowheads. The names of data areas and of processes are written into the rectangles and circles. Simple examples are given in Figure 5.1. 5.7 DATA RECTANGLES Data rectangles can be used to represent either files, lists, buffers, arrays, tables, identifiers, etc. or the words, characters, bits, etc. of peripheral sources (keyboards, input typewriters, registers, etc.) and sinks (displays, output

53

INPUT

-^PROCESS

OUTPUT

Fig.S. 1(a)

A procedure named "process" reads data named "input" operates upon it and writes the result into data area named "output" Note: In Coral 66 terms "input" is a value and "output" is a location

UPDATE K-

DATA

Fig.5.1(b)

A procedure named "update" reads, transforms and writes back data named "data"

Fig.S. 1(c)

A procedure named "mix" reads "data" and "data 2", operates on the data and writes the result into "data 3"

54

(NAME)

Process (program, procedure, sub-routine, macro, block, statement)

NAME

Data (source or sink)

* > s

Data flow Program initiator implying temporary transfer of control (link, procedure call) v /> Program initiator implying permanent transfer of control (jump, goto) Program initiator implying the connection between two separately designed systems (system call) External (hardware) interrupt

V~>

^ =

>

-^wvwv-^

Fig.S.2(a)

Basic symbols

PUNCH

\//A

Peripheral device (data source or sink) Circular list or buffer with input and output pointers

Hardware nterrupt generator

"DARD,

Hardware data source/sink and interrupt generator Program which for some purposes may be classed as data

Stf
-V

r/^rr ~yy~

chain linked list

O w
O/P

l/P Parameterless procedure call Procedure call with input parameter(s)

Procedure call with out parameters

Ar

ro/pi

Ar

Q3D
^ % Parameterless system call
^

ITpl
System call with input parameters)

Procedure call with input and output parameters

Jk4
4th output System call with parameter(s)

% System call with input and output parameters Fig.5.2(b)

m v
Procedure call when dat data areas omitted (optional)

Variants of basic symbols

55 typewriters, registers, etc.). Each rectangle must contain an unambiguous and meaningful name (unabbreviated if possible) which is consistent throughout the documentation. If there are equivalent names or if a data area is broken down elsewhere into elements, a complete index of names must also be provided. Cross-hatching of hardware data rectangles is recommended to distinguish them from software sources and sinks. Figures 5.2(a) and 5.2(b) show the types of basic symbols used. Only simple arrowed lines may be connected to data areas.

Fig.S.3

Simple hierarchic program network

5.8 PROCESS CIRCLES A process circle represents a function whose behavior is independent of its activation. In programming terms there must be only one entry point. Process circles can be used to represent procedures, sub-routines, macros, coral 66 blocks even simple statements. Processes are usually activated by other processes, but they can also be activated directly by hardware (external interrupt). Processes should preferably be written as procedures (or macros) and are therefore activated hierarchically by other procedures. The external interrupt connection between hardware and process is quite different from the data transfer between hardware and process and data areas are conceptually possible, but direct connections between one data area and other (i.e., without an intervening process) are never allowed. Types of process activation are illustrated in Figure 5.2(a). The distinction between these forms is primarily a question of control, i.e., the place where control exists before activation and the place where control is passed after the process terminates. As far as the process itself is concerned, there is only one entry point. The behavior of a called process is therefore independent of the calling process except insofar as it is modified by actual data. The four methods of activation of processes are: (1) External activation (by hardware interrupt). Here control is temporarily transferred to the process at a time determined by external hardware. Thus in practice control is transferred from an indeterminate point in an indeterminate process and on completion of the process or processes, control returns to the interrupted process at the point of interruption. (2) Sequential activation. In this case one process permanently transfers control to another. The last obeyed action of the calling process must be a GOTO label (or jump) where the label is the name of the called process. To avoid unnecessary distribution of control, this form of activation should be avoided where possible.

56

(3) Nested (or hierarchical) activation. This is the procedure (or sub-routine) call, where one process, at a predetermined point, temporarily transfers control to another, control returning to the calling process at the point of interruption. Nested activation can also be used to represent the effect of a Coral 66 (Algol) block. This form of activation is preferable to sequential since it expresses the hierarchical relationship between processes.9 Input parameters may be passed to a sub-process which may subsequently return answers to the calling process (see Figure 5.2(b)). (4) System activation. This form, which can often be omitted in diagrams, is used to represent the transfer of control, at a predetermined point, from a process in one sub-system to a process in another subsystem, being cooperating, parallel acting, or separately designed. This form of activation would be used to describe the interaction between a program and a time-sharing operating system which handles more than one program. However from the application programmer's point of view, system activation might resemble any other procedure call. 5.9 EXAMPLE OF A SIMPLE HIERARCHIC PROGRAM NETWORK Figure 5.3 shows a simple network which illustrates some of the above features. The diagram is not based on an actual program. The sequential activation symbol indicates that the program starts by activating process x . The absence of "STOP" indicates that process x never ends. Process x can call processes y and z and process y can call process z. The process circles can be arranged vertically in hierarchical order so that x is first level, y is second level and z is third level (i.e., all calls are downward). It is not intended that the diagram should reflect any time sequences of events, i.e., the sequential activation symbol has not been used (apart from START). The supplementary documentation will carry the following information: (1) An overall explanation of the program in terms of x, y, z, fred, John and harry. (2) The detailed data descriptions of fred, John and harry including an index of their sub-names which seem in the corresponding program texts, i.e., fred or parts of fred are referred to in x and y , john or parts of John are referred to in x, y and z , harry or parts of harry are referred to in y and z. (3) A description of x, y and z in the following forms: (a) In plain English, (b) In outline language (e.g., pseudo coral), (c) In Coral 66 (or alternative language). Note that program z will not refer to x or y , program y will refer to z only, program x will refer to y and z . Although the network of Figure 5.3 is purely imaginary and the supplementary information is not available, it is nevertheless possible to describe the program in some detail. Process x has an internal loop or loops which ensure continuity and this process updates fred using john data. It call two sub-processes y and z which use fixed constants called harry. Process y also uses fred. The purpose of y and z is to produce john data for x . The overall purpose of the network is to provide fred data for output or onward transmission. This data is provided by x from john data, which is itself produced with the assistance of y or z or both. There is also some feed-back since sub-process y uses fred data. Note that the number of times x calls y and z and y calls z (or even whether they are called at all) is not revealed by the diagram since this depends on the algorithm concerned and the actual data. 5.10 HIERARCHY OF DIAGRAMS A fully detailed network diagram of a very large program will contain many rectangles and circles. To avoid complexity and to aid comprehension, large networks should be prescribed in hierarchical fashion such that each diagram is an expansion of part of a higher level, simplified diagram. Each diagram should contain less than about twenty or thirty rectangles and circles. No software system, even the largest, should therefore require more than five or six levels of documentation, although the number of lowest level diagrams would be quite large in this case.

57

LEVEL 1

LEVEL 2

LEVEL 3

LEVEL 4

LEVEL 5

LEVEL 6

Fig.S.4

Procedure call diagram

An hierarchical program network should be simplified by the following rule: A sub-process activated by only one process can be regarded as a part of that process and so can be "eliminated' by merging it with the activating process, adding its activating arrows and data connections to the joint process. Figure 5.5(a) shows the effect of following this rule on the network of Figure 5.3. Note that process x (now including y ) writes data into the data area called john, but the three data areas cannot be omitted since they do not belong solely to any one process. Figure 5.5(b) shows the result of a second simplification. It is now permitted to eliminate process z since it is now called by x only. Figure 5.5(c) shows a third simplification, permissible because all three data areas now have simple connections, "sam" being the name of all three data area. Similarly, the network of Figure 5.4 may be progressively simplified as shown in Figure 5.6. Firstly, we can eliminate b, e and g. Note that process a must activate process f since it now includes process b . The second simplification reduces the network to process a and process f and a third simplification eliminates process f. In general, any programming network can be progressively simplified in this manner except in "pathological" cases where every process is activated by more than one other process. This only occurs when there are loops which means, in the case of nested activation, recursion. Figure 5.7 shows a highest level network simplified to the point that it could be said to describe any real-time computer-based system. There are only two processes, one being software which operates on inputs from automatic and keyboard sources and provides output data both for automatic control and human recognition. The human is regarded as a "process" too complex to replace by software.

5H

START

Fig.5.5(a)

First simplification

START

Fig.S.5(b)

Second simplification

START

SAM FRED & HARRY & JOHN

Fig.S.5(c)

Third simplification

59

START

START

Fig.S.6(b)

Second simplification

Fig.S.6(a)

First simplification

ENVIRONMENT DATA SINKS

DATA SOURCE

DISPLAYS

KEYBOARDS

Fig.5.7

Real-time computer-based systems

60

Fig.S.8(a)

Simplified real-time system

TIME SIMULATOR

P2

'ENVIRONMENT ^SIMULATOR

j r

INTERVAL TIMER

am

P1

DATA JKt STf

p ?

INPUT DATA

Fig.S.8(b)

Simulation of system shown in Figure 5.8(a)

61 5.11 SIMULATION AND TESTING Program design could be described as the expansion of a higher level program network into lower level detailed program networks. The production stage could be described as the integration of lower level networks into a higher level network. In the latter stage, each progressively larger group of modules (rectangles and circles) is surrounded by test modules culminating in the simulation of pheripheral hardware. These test data and simulation programs should also be described by program networks. (See Figure 5.8.) 5.12 REAL TIME COMPUTER SYSTEMS The majority of computing is concerned with computation for business or scientific purposes. In these applications, a program is written which takes in some data, transforms the data into some other form and outputs it to a printer, plotter or graphical display. Nowadays, a computing service is set up to do this for a number of independent users who share the computing facilities. A user's individual results do not depend on the time taken to perform their computations, i.e. they are not "real time" programs in the normal meaning. (In practice users are very concerned about "turn around" time so that the term "real time" is often ambiguous.) Continuously running within such a computer is a complex (and often very large) program which organises the separate computations (by "batching" or "multi-programming") and controls the various peripheral equipments employed. Such a program, or rather, system of programs, is a general purpose "operating system". Although not often thought of in such terms, an operating system is an example of a complex real-time software system dedicated in this case to the special functions of a multi user computing service, namely the preparation and running of a wide range of unknown, individual, user programs. Since each "user" is intentionally shielded from knowledge of its inner workings, the operating system can well be regarded as an extension to the computer hardware and indeed modem machines are being designed with this in mind, particularly for real-time applications. The kind of real-time system with which we are concerned in this book differs markedly in certain respects. In the first place there are no user programs as such and so a wide range of back-up software is not normally required. Secondly, there are additional peripheral equipments to control which are foreign to a conventional computing configuration. These control programs are usually regarded as part of the "application programs". A real-time operating system therefore has fewer functions to perform than a general purpose operating system. In a very simple real-time system the operating system itself could virtually vanish as a separate entity, all its functions being performed by the application programs themselves. Depending on the range of peripherals and the range of functions to be performed by the system, the dedicated real-time system can be much simpler or more complex than a conventional general purpose operating system. However, the complexity of most modem real-time systems necessitates sub-division of the software into smaller interacting sub-processes. It follows that, unlike conventional programs, real-time programs are more than merely algorithms and should be regarded as software systems. Simpler types of real time on line systems would be fully automatic, but more complex systems permit manual intervention and supervision. Such systems also refer to and maintain a data base. The stored contents of a real time computer therefore consists of messages (communicating with the peripheral hardware), variables (the data base) and "pure" program. During the early stage of building such a real time system the elemental sub-programs can be regarded as independent computations so that a simplified form of computing service with support facilities for compiling, editing, loading and testing is required. In general, such facilities have been poor in the past since the kind of computers used for dedicated systems tend to employ computer hardware not normally intended for a general computing service. There are two ways to overcome this difficulty. One is to provide a program development facility specially for the development of the system, the other is to develop the system on an existing different facility. The latter method is adequate for the early stages, but requires the programs to be easily transferable. When the final stages of integration of the sub-programs with the particular sensors take place, the general computing facility is inadequate and some means of testing and development on the object machine is essential. As a result of past difficulties, much more attention is now being given to program development systems for real time computing projects. A real time program consists or can be viewed as consisting of a number of interacting continuously running sub-programs specially designed and dedicated to respond to and control input/output peripheral hardware for some overall purpose. The concept of continuous "parallel" running of programs is very important in real time systems. Of course, from a lower (machine code) level viewpoint, most computers in fact permit very little parallel operation; perhaps one central processing unit, with a separate input/output channel to the main store. At the lower micro unit system level, all operations are sequential, unless there are separate stores. Some "multi processor" computers have separate stores and processing units, but these are still comparatively rare. The software problem arising from the continuous running of programs "in parallel" are the main "techniques" difference between real-time systems and ordinary user computations. Fundamental to the parallel running of a set of cooperating processes is the means of interaction and the techniques of activation of processes. Two main methods of activation are used, one (asynchronous) analogous to a postal service or in/out tray where signals are polled, the other (synchronous) analogous to a telephone in that

62

processes are interrupted. Interrupts are used by external hardware to activate processes and these in turn interrupt other processes. (It is interesting to note that an interrupt, viewed at a lower sytem level as digital hardware logic, is achieved by polling techniques nevertheless.) In dedicated real-time computer systems the real-time response of the system (including the collection of subprograms) is vitally dependent on the particular requirements of the system and on the peripheral hardware employed. The system programs must take into account an environment determined response time. We can therefore distinguish two extremes in real time computing systems, those in which a slow response to manual intervention is merely inconvenient and systems which would fail if a particular process (running of a sub-program) did not respond in time to a peripheral hardware interrupt. Important intermediate cases also described as real time are transaction processing, dedicated systems whose function is to handle as much traffic as possible such as air traffic control (where overall response time is particularly important) or (less real time) air-line booking. There is no doubt that some of these distinctions are more apparent than real and that the general trend in computing is towards more "real time" and to some extent towards more dedicated systems. Possibly the true differences between computer systems are connected more with objectives such as response time, throughput, integrity, security, reliability, flexibility, adaptability etc., than with the extent of real time operation. 5.13 HIERARCHICAL VIEWPOINT Complex systems are difficult to design and even to describe. As in other fields, a common descriptive technique is to start with the broad features and proceed in a series of steps of increasing detail towards elemental components. From such a "top-down" hierarchic systems viewpoint, our subject encompasses a number of distinct levels. At the highest level we have the user's view. Here the system is described functionally, i.e. in terms of what it can do. This description should hopefully match the original operational requirements. The next level describes how this is achieved in terms of manual operators and peripheral equipments viewed as sources and sinks of data and control signals. The applications software occupies a specially important role at this level as it is both the glue which holds everything together and the central means by which the functions are carried out. For this reason our systems are more accurately described as "software based" rather than "computer based". This software is sub-divided (perhaps through several sub-levels) into a large number of simple algorithms. Each algorithm is described in a computer language which is translated (by a special compiler program) into binary code. Here we arrive at a description of the computer. The binary code is interpreted by digital hardware into microprograms (sequential sets of standard gating pulses) which control registers and store locations consisting of sets of semi-conductor packages etc. Of course, it would be unlikely that a new avionics project would involve simultaneous design at all these levels. Nevertheless, independent developments cannot be ignored. As is common in systems work, designers at any one of these levels would prefer the lower level technology to be static and standardised since this simplifies his problem, but on the other hand, technological advances in lower levels offer him new possibilities. Some examples of these interactive problems are: the effect of rapid technological advance in the semi-conductor industry on computer design, the matching of computer architecture and machine code to the growing need for better operating systems and high level language programming, the design of high level languages which are reasonably powerful, stable and standard, cover a range of users and yet make proper use of improved computer hardware and, perhaps most pressing for the avionics system designer, the relationship between programming and system functions. Until quite recently, it was generally believed to be essential to program real time systems in machine code. This created a very wide gulf between the user's view of the system as a set of operational functions and the assembly code programmer's viewpoint. This gulf is being bridged by growing realisation that a real time program must be sub-divided in some way and that "efficient" assembly language programs can be bought at too great a price in complexity. The idea of using computers to control equipment is comparatively recent. At first, real-time programs were written in the individualistic style of conventional programming by programmers who often knew nothing of engineering. Such programs were comprehensible to the programmer only and led to obvious difficulties in development and maintenance. When teams of programmers were involved this could lead to chaos. Nowadays, the accent has shifted from ingenuity and run-time efficiency towards comprehensibility and structure. The greater use of diagrammatic documentation techniques and high level languages is part of this emphasis. Much remains to be done here. A major impediment to the exploitation of the computer in engineering systems is the relative difficulty of "explaining" the workings of a program compared with the workings of complex hardware. It is as if electronic equipment could be studied, analysed and comprehended only in terms of detailed wiring diagrams.

63 As computer systems become less of a novelty, standardisation at lower levels, though restricting possibilities, offers the avionics system engineer fewer problems, assuming he is prepared to make use of existing technologies. For example, if he is content to use "off the shelf hardware and a standard language for real time programming, his basic elements are statements in computer language. On the other hand, if he wishes to use a new computer architecture with novel instructions he may be forced to extend a standard language or even redesign it. Similarly new digital circuits may lend themselves to new computer hardware concepts.

REFERENCES
1. White, Tauber, 2. 3. Emery, F.E., (Ed.) 4. Boguslaw, R. 5. Klir, G.T. 6. Mesarovic, M.D. etal. 7. Langefors, B. 8. De Greene, B. Kenyon (Ed.) 9. Naur (Ed.) Randell (Ed.) 10. 11. Smith, M.H.A. 12. Hdy, M.H.M. 13. Woodward, et al. 14. Phillips, C.S.E. 15. Jackson, K. Prior, J.R. 16. Jackson, K. Systems Analysis, Saunders, 1969. Political Economy of Efficiency, Public Administration Review (USA) December 1966, also C.A.S. reprint No.2 HMSO. Systems Thinking, Penguin, 1969. The New Utopians A Study of System Design and Social Change, Prentice Hall, 1965. An Approach to General Systems Theory, Van Nostrand, 1969. Theory of Hierarchical, Multilevel, Systems, Academic Press, 1970. Theoretical Analysis of Information Systems, Student Litteratur, 1966. Systems Psychology, McGraw Hill Series in Management, 1970. Software Engineering, p.47, 186, 204, NATO Publication 1969. A Guide to the Development of Computer Based Systems, I.E.C.C.A. (P) 4/72, Royal Radar Establishment, MOD(PE). Syntactic Description as a Means of Writing Computer Programs, A.S.W.E. Tech. Report TR-70-4, July 1970. Syntax Analysis as an Aid to Sytem Design, RAF, Radio Introduction Unit, RIU/126/1/AIR June 1972. Official Definition of Coral 66, HMSO 1970. Networks for Real Time Programming, Computer Journal, Vol.10, No.l, May 1967. (An early description of program networks as used for an automatic radar program.) Debugging and Assessment of Control Programs for an Automatic Radar, Computer Journal, Vol.12, No.4, November 1969. (This article refers to program networks for program testing and the simulation of peripheral hardware.) An Experimental Operating System Written in a High Level Language, Software Symposium on experiences with software in Computer Control Applications, Institute of Measurement and Control, July 1969. An Exercise in Program Design, Inter Establishment Committee on Computer Applications, IECCA(P) 6/71 Ministry of Defence (PE), UK. (A detailed description of iterative top-down program design using networks extensively.)

17. Jackson, K. D.E.Buchan (Mrs)

64

CHAPTER 6

AVIONICS SYSTEM ARCHITECTURE R.E.Wright

6.1

INTRODUCTION

The system architect's task is to define and combine a set of hardware components to form a system whose aggregate behavior will meet the operational requirement for the system. Most avionic systems start with an operational requirement specified by a user or air-frame manufacturer. During the short history of aviation there has been a growth of such operational needs which have presented problems requiring technical solutions. There has also been an evolution of technologies to meet such needs. The two processes have to some extent proceeded independently, becoming locked together whenever a major project requires implementation of hardware, when it is the task of architectural design to meet operational requirements with components which meet the system constraints and are within the "State of the Art". This design process may well necessitate compromises in the operational requirement should a fully compliant solution be impractical on technical or economic grounds. The avionic system derives much from the general developments in system engineering, but is subject to particular operational requirements, physical environments and physical constraints which together justify a somewhat specialized approach. The operational requirements imply some target for the reliability of a system which is dictated by requirements for mission success and aircraft safety. The reliability of a system can be expressed as the probability that it will perform a specified mission. The advent of digital computers in the 1950's offered a potential solution for an increasing operational need for precision in calculation and data transfers associated with navigation and weapon delivery. However, the early digital computers, based as they were on thermionic valve circuits, could not survive or operate reliably in the relatively hostile thermal and mechanical environment of aircraft, nor meet competitively the physical constraints of size, weight and power consumption. The digital computer was thus initially confined to a ground environment, and ground-based systems for the tracking and control of aircraft were developed for both commercial and military applications. This work included the development of data links for the transmission of information in digital form over wire and radio links, both between ground sites and ground-to-air. A dramatic change was brought about by the development of the transistor, the magnetic core-store, and subsequently the integrated circuit. These circuit techniques made it feasible to develop computer equipment for airborne use. There are now available and in development a variety of digital computers suitable for airborne use. This chapter will be concerned with the design of systems involving digital computers as "components" and the design methodology at that component level. The early aerospace applications of digital computers were substantially real-time, the computations being performed using data simultaneously acquired by the computer system and the output from the system being used to give directions to operators or control systems. Such systems existed very much in an analog world. Input parameters (such as pressure, air-speed, aircraft heading) were continuous and usually presented to the digital system in electrical analog form (i.e., dc voltages, synchro waveforms, etc.). There has since been a widening application of computers to cover management functions and signal-processing, some aspects of which are not required to be performed strictly in "real-time". At the same time transducers and other systems have tended to use digital techniques and provide digital interfaces. However, the changes have been largelyuncoordinated and often present the system designer with unnecessarily complicated situations. A major consideration in any manned aircraft is normally the safety of the crew and passengers. Analog equipments, including radio equipment, have developed largely in an uncoordinated way, each new flying aid or facility generating its own standards and equipment. Once established as a generally recognized facility individual equipments have been developed by a process of evolution, but in general have been resistant to radical change. Reasons for this include the undesirability of changing displays, facilities and controls with which air crew have become familiar and the cost of replacing existing in-service hardware. New equipments have been accepted but have not in general replaced the established facilities. This situation has produced an embarrassing accumulation of hardware, but the very duplication and redundancy of facilities has the attraction to the operator of lessening

65 his dependence on any one system and the separation of systems minimizes the chance of propagating faults from one system to another. Digital techniques offer the possibility of combining some of these systems, but in doing so the system architect must endeavor to maintain the level of system integrity to which the user has become accustomed. The need for safety has led to the establishment of national agencies charged with the specification and control of design standards for avionic systems, both military and civil. These bodies have produced a maze of specifications and procedures of which the system designer must have cognizance. However, aviation is an international business and aircraft have to interact with ground-based facilities. This has led to the necessity for defining international standards for some system parameters (i.e., radio frequency allocations) and equipments. International military standards are usually agreed on an inter-government basis. Standards used in commercial aviation are also determined on an inter-government basis, but the operating airlines and the supplying avionics industries have formed associations and agencies (such as the Aerospace Industries Association, the Airlines Electronic Engineering Council. ARING and EUROCAE) with the aim of consolidating opinion among the participants so that recommendations can be made to governmental bodies, airframe manufacturers and equipment suppliers. It can be extremely important to the viability of a commercial system development that it is, or can be made to, fit within the framework of an internationally agreed specification. Most aerospace digital computers use the binary number system. Each digit of a binary number can be one of two states, '0' or '1'. Thus binary digits (or "bits") can be represented by a variety of physical devices that have two distinct states, such as a switch that is either "on" or "off", or an amplifier output which is either "hard on" (low voltage) or "hard off (high voltage). A binary number or code of several digits forms a word. Words can be represented and transmitted electrically either as a time sequence of two levels of signal on a single wire (serial operation) or as a set of simultaneous signals on a set of wires where each wire corresponds to a particular digit (parallel operation) or a combination of the two (serial-parallel). The two-state nature of the signal enables thresholds to be defined such that appreciable degradation from an ideal signal can occur before a '0' or T state is incorrectly identified. Also drcuits can be compounded to give words of any length, so that once quantities have been converted into digital form it is possible to transmit and record them without loss of accuracy, and to perform calculations with them to any desired precision. The trade-off is primarily between accuracy and hardware. Typical word lengths for data in aero-space systems lie between 12 and 24 bits. Computer architecture can include a range of the word lengths for both data and instructions within the same computer. The potential advantages of digital techniques at a system level include maintenance of accuracy of encoded data during manipulation, adequate computational precision and range of computing power (including use of special purpose processors, for example for spectral analysis) range of techniques for filtering and mixing of information (often without the time lags inherent in other approaches), automation of operating mode selection (reducing operator work-load), multi-plexing wire-sharing techniques (with consequent weight saving), data manipulation for communication with operators, crews and with other systems (making the use of electronic displays feasible), possibility of storing library information, including flight manual and maps, in digital form in backingstorage (with a consequent weight saving and ease of up-dating and access), possibility of automatic fault detection and mechanizing failure survival, relative ease of system development and optimization (including the use of standard hardware and software modules). These advantages alone can make digital techniques essential to meet certain operational requirements, but this is re-inforced by the continuing rapid development of digital hardware technology. Developments in MOS and Bi-polar semi-conductor technology, thick-film, thin-film and printed circuit interconnection techniques, circuit encapsulation techniques, and electro-optical techniques have considerably widened the range of physical environments and constraints for which digital systems are practical. The predominant development is the socalled Large-Scale Integration technique(L.S.L), whereby some hundreds, even thousands, of digital circuits (e.g., gates) can be accommodated on a single semi-conductor chip. This will make available an increasing range of L.S.I, computers, memories, input-output multiplexers, etc., at significantly reduced quantity production prices, so that the system architect will be able to make more liberal use of processors and memories, and be able to trade logical multiplexing of signals for wiring.

66 6.2 THE PRACTICAL APPROACH As computer systems have continued to grow in complexity and sophistication it has become increasingly recognized that to design, analyze and document a system a number of levels of system description are necessary. These are not alternative descriptions, each level of description arises from the abstraction of the levels below it. A hierarchy of levels can be identified, each level has associated with it distinct "language" for representing its components, modes of combination and laws of behavior, albeit that the language may be expressed in both algebraic and graphical form. Bell and Newell1 identify four main levels: the circuit level; the logic level, the programming level, and the Processor-Memory-Switch level (abbreviated to "PMS level"). It is with this PMS level that we are mainly concerned here. The system is conceived as an inter-connected processing system. The medium flowing through the connections is information, which can be measured in bits (or digits, characters, words, etc.). The components of the system are modules with information handling characteristics, including capacities and flow rates. The methodology of combining such components is system architecture. A definition of avionics systems architecture is then: the combination of programmed processors, memories, switches, controls, communication links, peripheral control/interface units, peripherals/transducers to perform a defined combination of operational and control tasks, subject to partitioning and packaging dictated by the physical environment and requirements for maintenance. However the system architect must also be concerned with other levels of system description, the lower levels of programming and logic, and a rather ill-defined higher level concerned with the interaction of the computer system with other major systems, including possibly other computer systems. This higher level of system description (Major System Level) is necessary to determine the functional requirement of the computer system, and will be considered further in another section. The primary components of PMS systems are defined by the set of operations they perform. In general the primary components consist of PMS structures of other components. Primary components interconnect with each other at communications interfaces called "ports". Here we will content ourselves with allocating single-letter names to primary components and defining the roles the components play in the system structure. A more detailed notation is given in Reference 1. I-unit: A hierarchically organized information structure, in which each level consists of a number of sub-units, all identically organized. The basic unit of information is usually the bit. Information rate, as measured at a port for instance, is the flow of I-units per unit time. A component for transmitting I-units from the port of one component to the port of another. A link permitting transmission in one direction only is normally called a simplex link, a link permitting transmission in both directions is called "full" or "half duplex, depending on whether the transmission can take place simultaneously in both directions or not. The I-unit can be transmitted as a message block, of width determined by the number of basic units transmitted in parallel and of length the number of widths transmitted serially in one operation. The physical realization of links as wiring is often termed a "highway" or "bus". A memory is a device for storing information, and indeed the term "store" is used synonymously. It consists of an array of locations in which I-units (i.e., words) can be stored. The two main operations are reading, in which an I-unit presented at an input port to the memory is transferred to a location, and writing, in which the I-unit in the location is presented at an output port. The information defining the address of the location used may be supplied by the component accessing the store information of some different component. The information rate is the information in the stored I-unit times the operation-rate. A potential means of linking sets of input and output components. It is actuated by an address which determines the sub-set of links to be connected. A pair of connected links that have different I-units, or underlying carriers. Although the meaning of the information transmitted is preserved the amount of information may not be. At a higher level of PMS structure a transducer may represent an analog-to-digital interface. A logical circuit that evokes operations in other components. This component creates information, It takes information as an input, operates on it, and presents the result at an ouput. A component which operates with memories to perform a sequence of operations, including data-operations, on I-units from memory. Each operation sequence is determined by an instruction (or "order"), and the component can be characterized by its instruction set. A distinguishing feature of the processor is that it determines its own next instruction. This is achieved by adopting instruction formats which enable sequenced instructions (i.e., a program) to be held in memory, the address of next instruction from the memory to be used being determined by the processor itself.

L-Iink:

M-memory:

S-switch: T-transducer:

K-controI: D-data operation: P-processor:

67 C-computer: This is a combination of processors, memories, transducers, switches and controls that can perform information processing under the control of a common program. Such a computer with more than one processor is called a multi-processor computer, and a distinction should be made between this and a system complex involving more than one processor obeying separate programs; the latter is a "multi-computer system". It should also be noted that that part of a computer dedicated to servicing a particular port is sometimes termed a "channel". A collection of two or more computers not interconnected via a primary memory (e.g., a memory holding directly executable programs).

N-network:

An example of the use of this notation is given in Figures 6.2 and 6.3 which show the same typical computer system in block diagram form and PMS notation respectively. The notation is not necessarily comprehensive, the level of analysis of the structure of each component in terms of its own PMS structure being at the discretion of the user. For example in the diagram the Input/Output Controller is represented as a switch, although it will probably have controller (K) and memory (M) components. It is also possible to describe and classify the components in more detail, by both the use of subscripts as shown in the figure, and by the addition of abbreviated text using a formalized language defined in the reference, which allows all the normally important attributes, parameter values and options for data processing components to be defined. For example the notation for Mp could be Mp(core; (tc: 1 ws/w; 4 Q96 - 32768W; (24 + l)b)/(tc: 650 nS/W; 16384 - 32768W; (24 + l)b) indicating a core memory with two options, a 1 JUS cycle-time (i.e., time to read a word from memory and replace it) memory expandable from 4096 to 32,768 words and a 650 ns cycle-time memory expandable from 16,384 to 32,768 words, both memories giving a 24 bit data word output with an additional bit (e.g., for parity). The full PMS notation appears to be a useful tool for analyzing and classifying computers and computer systems. However as yet it has no general acceptance and is not the form in which actual hardware is specified by manufacturers, and it has yet to be established as a practical notation for system design. However, the system designer must use some form of notation, and the PMS notation has been introduced here to illustrate the components that must be allowed for. Aviation electronic hardware is normally packaged in the form of equipment modules (the so-called "black boxes") which are interconnected via plugs and sockets and a wiring harness. The modularity has partly been dictated by ease of maintenance, each box being a Line Replaceable Unit (L.R.U.) which, when it fails, can be replaced by an identical unit as a means of first-line servicing. It also has attractions to the equipment manufacturer, as each black box can perform a specified system function which can be tested, by providing test-signals at its plug and socket interfaces, before being installed. This general approach has enabled the air forces and air lines to specify function, mechanical dimensions, and plug and socket interfaces of equipment to manufacturers, while allowing manufacturers reasonable freedom in choosing the technology and design of the equipment within the box. In particular a range of modules to the ARINC 404 Specification have been developed covering a wide range of equipment. It is now common practice to fit a particular equipment into a variety of aircraft types. For air forces and air lines operating a number of aircraft types such use of common equipment has significantly reduced the amount of training and logistic support required. At first most black boxes used analog techniques and communicated using analog signals. The use of digital techniques within the equipment has evolved slowly and where digit transmission links have been used between units, the transmission standards have often been specified on a per system basis. This has already led to a proliferation of data link standards, although ARINC have suggested a common method of classification. Figure 6.1 shows a typical system diagram involving such standards. There appears to be room for rationalization in order to allow more flexibility in system configuration. A general practical apprach to the design of future digital hardware modules will be to define the system at the PMS level, determining information flows, information rates, and processing loads, including an analysis of the interfaces with the analog world via sensors and transducers. The components can then be partitioned into suitable L.R.U.'s with defined electrical interfaces. Ideally the number of types of interface should be rationalized, so that alternative configurations of the same modules are possible to meet other operational requirements. The processing loads determine the type of processor required and the number of words of memory required by the program. The computer program is made up from instructions concerned with execution of the tasks ("tasks", "application" or "object" programs) and instructions required to regulate the flow of work ("executive", "supervisor" or "organizer" programs), In simple systems the organizer program may be merely concerned with ensuring that a sequence of tasks are obeyed or not, according to the system state. However, in more sophisticated real-time systems it is usual for the computer to be run in a multi-programmed mode, a number of programs being active at the same time in the same computer. Usually in real-time situations this will involve the facilities of a particular processor being time-shared between different programs under the control of the organizer program

bS

DME DISPLAYS

OBB.ABB/BABB/DBBA/BBB

>-ABB.ABB/BABB/DBBA/BBBB;

1 582

2
cou

582 CDU

o o o m m

t ol r i 1
o o co m

f
1

? 582 FDSU 582 FDSU 2 571 ISS

, w l 2
DADS DISPLAYS

li
o (J co m

DADS DISPLAYS

/\ '
>

U .\
>- o 3 671 ISS

u u m m

> > > > > ? >- > > > > > o > > o
>

n
a

1 571 ISS

> <> s o V CO
>
> CD

'1

'

> Si >- o

a > >H
CD

v y

> >

>> >

u
CO CO

> m

Fig.6.1

Typical avionics system interconnect diagram using classification system of ARINC specification 419

69

COMPUTER
A

PERIPHERAL CONTROL UNITS

A

PERIPHERALS
A

PRIMARY MEMORY

PAPER TAPE CONTROLLER CENTRAL PROCESSOR INPUT/OUTPUT CONTROLLER

PAPER TAPE READER

PAPER TAPE READER

KEYBOARDS COMPUTER CONTROL PANEL

SLOW SIGNAL MULTIPLEXER MISCELLANEOUS ANALOGUE SIGNALS

CORE MEMORY (BASIC FIT)

CENTRAL PROCESSOR UNIT

INPUT/OUTPUT CONTROLLER

CORE MEMORY (EXTENSION)

MAGNETIC TAPE INTERFACE

TAPE TRANSPORTS

MAGNETIC TAPE CONTROLLER PROCESSOR TO MEMORY HIGHWAY PCUTO I/O CONTROLLER HIGHWAY ('CLOSE I N ' O R 'BLEEDING STUMPS' INTERFACE)

O^O O'O

DISPLAY BUFFER UNIT

o o
K

C.R.T. DISPLAY CONSOLES

DATA LINK CONTROL UNIT

MULTIPLEXER/ DEMULT. MODEM

RADIO LINK

INPUT/OUTPUT HIGHWAY

/ \sf PCUTO PERIPHERAL HIGHWAYS

Fig.6.2

Block diagram of a typical computer system, showing principal 'highways' or 'busses'

70

T (Paper Tape Reader)

T. console

T (Keyboard)

Mp

Pc

Stm

' Stm

T (Analogue) T

Mp Ms Sfx Ms

T (CRT; display) -Stm T (CRT; display) M KT L (radio link)

Mp; Ms :

= =

primary memory, holds data and directly executable programs secondary memory, holds data and/or executable programs which are not directly executed. switch, time multiplexed. switch, fixed until changed (i.e. latched).

Stm : Sfx:

Fig.6.3

Computer system, as Figure 6.2, expressed in PMS notation (see text)

71 (see Reference 8). Computers typically have a variety of operating modes, task priority allocations, procedures and facilities for protecting data and program from corruption, methods of response optimization, etc., and may require a powerful control system comprising both hardware and software facilities. For the purpose of this chapter we will use the term "operating system" for this control system, and call the associated programs the "supervisor" programs, reserving the term "executive" for highest level of program control within a supervisor and any associated hardware. However, it should be appreciated that these software terms are often used synonymously in the literature. The specification of the response times of a real-time operating system can be complex, as they will depend on the system state and its previous history. As with the hardware a modular approach to the definition of programs, both task programs and supervisor programs, so that software can be reconfigured to meet other operational requirements, is potentially advantageous. In this design process other practicalities must be recognized. As avionic systems have become more sophisticated and complex there has been a corresponding requirement for advances in test philosophy and test equipment. A major development has been the increasing use of built-in test equipment (BITE) to monitor equipments during flight. This facility may involve monitoring by flight crew in large aircraft, but in small aircraft must be essentially automatic. Computer control of system testing offers potential advantages and this function may be performed on a time-shared basis by some computer in the system or by a computer dedicated to the task. A further consideration is the provision, characteristics and partitioning of power supplies. Although centralized power supplies for logic circuitry are potentially more economic both to make and to operate, the considerations of system flexibility and integrity usually lead to power supplies forming an integral mechanical part of the equipment they supply. Although the design of primary power supplies is often not under the influence of the computer system designer, there is usually some strategy in any particular aircraft whereby power buses are allocated to various services and there are usually special supplies for primary flight instruments and essential services. The computer system architect should try to utilize these services as appropriate for BITE and standby conditions associated with system failure and recovery. It is possible, in some applications, to arrange for failure of primary supplies to be detected while the equipment voltage rails are still within tolerance and for the system to be shut down in an orderly way under the control of the computer executive ready for re-start when the primary power is re-established. 6.3 METHODS OF ASSESSMENT OF COMPUTING POWER AND INFORMATION RATES It is typical of many real-time systems that the computational load and information rates can vary with time, and it is normally a design requirement for the system either to have a data-handling capacity sufficient to cope with peak-load conditions or to have built in procedures (e.g., priority structures of changes in operating mode) for handling peak conditions in a safe way. However the automatic detection of an impending over-load can be difficult to arrange and the detection facilities themselves may well contribute to the overload. Another parameter which must be estimated during the preliminary design phase is the memory size required for both program and data words. Ideally some method of analysis is required to determine the system work-load, and some measure of component performance is required so that the system performance can be matched to the operational load. Although this is a fundamental task for the System Architect there is as yet no completely satisfactory approach to the problem. The task involves system analysis, computer architecture and programming. The final stage of any such analysis is when the problem is defined, coded for a particular hardware configuration, and then mn (either on the actual hardware in real-time or by simulation) using representative system inputs. In practice it is usually necessary to make assessments of the necessary hardware and programming requirements at some earlier stage of analysis. Usually there are some constraints to the analysis, for example, it may be that only certain types of processors and memories of known characteristics can be considered. It is level, the originally design of usually necessary to analyze the computational requirements at various levels, namely the major system PMS level, and the programming level. A promising formal approach is developing from a discipline aimed at preparing maintenance handbooks, but which has been extended as a method of disclosing the a system, at various levels of detail, as it develops.

At each level of design at least four documents are required: - A functional block diagram defining the component functional units of the system or equipment, by showing the information flow between the units and in particular the main signal flow. It also allows the boundaries of hardware units to be defined. - A functional blocked text, laid out in blocks identical with those of the block diagram, with text (including mathematical relationships) describing the functions of each functional entity within that block.

72

A dependency chart, relating functional output to the events on which they are dependent. A signal specification listing all signals and their origin, destination and type. Having identified the functions to be performed a possible computer system can be defined at the PMS level and the functions divided into separately identified tasks or "jobs" which are then allocated to computers or processors. It is next necessary to establish whether each processor can meet the load placed on it. One technique for doing this is "job-mix modelling" (see Reference 3). Typically in an avionics system many jobs are repetitive. For a single iteration of each job the following parameters are estimated. amount of data and program obtained from each level of memory, execution time, amount of data returned to memory, input-output requirements, minimum periodic execution rate. Such an estimate involves the use of assumed processor characteristics and an estimation of the number of program instructions involved. Program estimation is a technique in itself (see a previous chapter). However, initial estimation is usually possible by some program analysis (i.e., macro flow-charting) allied with estimates based on previous experience. Programming for avionic applications has usually involved writing programs in some form of symbolic machine language or assembler language very dose to the instmction format of the machine, typically so that there is nearly a one-to-one correspondence between each program instruction and machine instruction. With larger programs now being required for certain airborne applications there are advantages in adopting a more linguistic method of writing programs, to ease communication problems between programmers and to reduce the problems of generating, checking and maintaining software. The use of such an approach requires the specification of "high level languages" suitable for real-time systems and the development of "compilers" to translate from the program written in terms of high level language statements to the instruction code format of the machine (see Reference 19). If programming estimates are made assuming a high level language, then translating high level operations to machine code is necessary in order to arrive at estimates of memory size. For some simple systems, where jobs can be executed in a fixed sequence and have no significant interaction, the sum of the execution periods of individual jobs indicates the iteration rate for the total computation cycle, which should be at least as high as the minimum periodic execution rate for each of the jobs. If it is not it may be possible to process critical jobs more than once in each main cycle. Where the computer forms part of a controlloop the techniques of sampled-data control theory can be utilized to determine the calculations necessary and their minimum rate. In many applications the job interact with each other, and with external systems. For example some jobs may be required to be initiated as the result of a stimulus (interrupt) from some other system acting autonomously. The processor will be controlled by some form of operating system, whose response times will depend on the state of the system and which will allocate computer time between jobs. Typically the following additional parameters may be involved in job-mixing modelling. interactions with other jobs, scheduling of other jobs via the supervisor, initiation of activities leading to future system loading. At some stage of the design of a new project one hopefully has some indication of the hardware configuration (including the number of processors), and indication of all or a representative part of the computational load of each processor, and the size of memories required for each processor. The characteristics offered by suppliers to match these system requirements would typically be in the form of an instruction set with execution times and data-rates and response times for input-output. How can a valid assessment of different processors required to perform a complex, but perhaps as yet ill-defined task, be made? Ideally from the assessor's point of view a single figure of merit would be desirable. One possibility is to determine the average number of instructions per second for each processor. However, this does not allow for size of data word being processed or the efficiency of the program word structure. A number of bases of figures of merit have been proposed, that of Knight 2 including processing time, input-output time, memory size and word length. A figure of merit for instruction processing can be calculated by weighting and summing the times for various classes of instructions. With no weighting one would add the times for each instruction and divide by the number of instructions to give an average instruction time. Simple initial assessments are sometimes made on one or two parameters (e.g., add, subtract, and multiply times). For simple single-address machines (e.g., only one address

73

specified in the instruction format) store cycle-time can give a rough measure of comparative performance. By analyzing the instruction mixes of actual programs for specific types of applications a number of sets of weightings or mixes have been established, of which the Gibson mix is probably the most well known. However, such factors as memory addressing structure and data-length must also be taken into account. The latter has been allowed for in some avionic assessments by indicating a distribution of required accuracies, so that shorter word length machines have to allow for more double or multi-length working in their mixes. There is a more sophisticated approach involving mixes that require specifications of a set of programs representative of the application, the execution times for which serve as a basis of comparison, or "bench marks" between competing computing systems. A significant advantage of this technique is that the total problem can be represented, including input-output and, if the program is to be written in some higher level language, compiler efficiencies. If the bench-mark represents a known fraction of the total computational load, the loading of the computer system by the bench-mark can be used as a pro-rata basis to establish whether the total system load can be handled. A comprehensive bench-mark will involve the use of simulated input conditions, and a sophisticated simulation may be necessary to determine worst-case conditions. Simulation can either be made in real-time on the actual machine, or in "simulated" real-time using a program model of the processor running on some other machine. In all assessments care must be taken to avoid unjustified bias towards one particular processor or processor characteristic. 6.4 GENERAL PHILOSOPHIES AND TRADE-OFFS In the previous chapter the allocation of functional tasks to processors was suggested as a trial design process. In fact there are a number of ways of re-allocating functions and re-defining hardware boundaries which can be employed by the system designer, but it must be appreciated that these do not alter the problem to be solved; they only lead to alternative means of solving it. We have so far implied that the processor is a conventional G.P. (general purpose) processor as defined in the previous section. In practice a number of other types of processor are at the disposal of the system designer. These include variations of the G.P. processor dedicated to specific computer systems tasks (e.g., input/output processors dedicated to the management of the transfer of information across the computer interfaces. Display Processors dedicated to the formation of data for C.R.T. display) or extended to give special facilities (e.g.. Array Processors which are structured to process data in the form of arrays of one or two dimensions). Another type of computer is the Special Purpose Processor, being usually a set of combination logic designed to perform a particular task. For example, the F.F.T. (Fast Fourier Transform processor) is designed to perform spectral analysis of a signal using the Cooley-Tukey algorithm (see Reference 7). Although in general the same tasks can be programmed on a G.P. computer the S.P. computer (using the same hardware technology) usually has substantially higher performance. It may also be advantageous to consider analog techniques (e.g., electromechanical and electronic analog computers) or analogous digital techniques. For example the D.D.A. (Digital Differential Analyzer) is effectively a set of digital integrators which are programmed by interconnection to perform in a way analogous to D.C. electronic integrators. They can be used to perform continuous calculations, such as resolution through heading or calculation of position from acceleration. As they can be elegantly realized using time-shared hardware several early air-bome computers were of this form. In the design of a major system it is usually necessary to determine the strategy for allocating functions to processors. This is the classic choice of distributed as opposed to centralized computations, the extreme configurations being: - a complete centralized and integrated system capable of performing all the required computations in a single computer (which could be a multi-processor computer). The tasks, which may be unrelated, are performed in a multi-programmed mode system, - a set of distributed processors dedicated to separate functions, loosely federated via a communications network to give the required total system performance. The centralized approach usually minimizes the computer system hardware content (because the same data manipulations and storage can serve several functions) and simplifies communication paths. However, the total system is vulnerable to a computer fault, the supervisory and control software can be complicated, and the testing and integration of the separate functional subsystems can be difficult. Distributed processors offer the possibility of reduced total software development (provided that the software of each subsystem is transportable from one system environment to another due to "functional" interfaces - for example an inertial-guidance platform and its computer can be used as a module in different systems), reduced system development time (because subsystem development can proceed largely independently and in parallel until

74

final integration), simpler system installation and trials (as each subsystem is largely autonomous), greater system fault tolerance (a single fault should affect only one subsystem). In practice most major avionic systems will be a compromise between the two extremes, e.g., some centralized activities and some dedicated processors. Communication of information in digital form between peripheral subsystems and computers takes place over groups of wires, often called highways. If one looks at simple computer systems, such as that shown in Figure 6.3, a number of highways and associated interfaces or ports can be identified. Peripheral device to peripheral control unit (P.C.U.) interface. This is largely dictated by the peculiarities of the peripheral and may not be under the System Designer's control. The interface may include analog signals, which require conversion in the P.C.U. to digital form using the techniques of a previous chapter. P.C.U. to computer input/output controller highway. Controller to processor highway. This is usually closely dictated by the detailed design and timing of the processor, and is therefore not controlled by the System Designer. Processor to memory highway. It should be noted that some of these terms (such as P.C.U.) are not universally accepted and other syndromes may be encountered. However, in principle all specific realizations of these components can be represented in terms of a PMS structure. In general data is required to be transferred between the peripheral and the processor memory, where it can be manipulated by the processor. This process is analyzed in more detail in Chapter 3, but here we will just recognize the three modes of data transmission that are possible, via the processor under program control, the processor being devoted to the task at that time. via the processor under the control of the input-output equipment the processor "hesitating" in its normal routine. Intervention by program is normally required at the end of a data transmission sequence (e.g., a "Program Interrupt"). This type of input can be arranged to be either processor initiated or peripheral initiated. This form of input has been termed "Data Interrupt". direct into the processor memory, by-passing the processor. This technique requires a memory highway either from the I/O controller to the memory or from the peripheral P.C.U. to the memory. Again some intervention by program is normally required at the end of the sequence. This technique is a form of direct memory access (D.M.A.). The concept of memory modules allowing both processor and peripheral access is called "Ported Storage". Of the four highways classified above, two, the PCU to I/O Controller highway and the Processor to Memory highway, can be influenced by the System Designer. There is a good argument for the standardization of these interfaces, with resultant advantages of system flexibility. However, the interfaces must be designed to handle the most demanding peripheral, and there are numbers of ways of implementing the basic features needed by the highway system. The I/O Controller and PCU for example must: be able to access the processor memory without corrupting other processor activities, be made to interpret words from the computer as either data, control or addressing and pass these to be peripheral; and to send data, addresses, and information about the status of a peripheral to the computer, provide any buffering memory necessary to prevent the peripheral holding up the computer, provide some method of allocating priority of service to peripherals, so that simultaneous requests from service can be deat with. Individual manufacturers have been able to standardize on I/O interfaces and memory "ports" and the associated engineering and programming codes of use, but little success has yet been achieved at defining international standards covering a range of peripherals and memories. Some manufacturers have adopted common I/O and memory interfaces, which offers interesting system configuration possibilities. However, there are disadvantages to this, as the memory interface may be of higher performance (in information rate) than is justified for input/output. Consider the design of a highway system (e.g., links, switches and ports) to interconnect a single I/O controller fitted with a number of ports with a number of peripherals. Assuming duplex links and switches it would be possible to interconnect I/O ports with peripherals using a cross-bar switch (as shown in Figure 6.4). Such an arrangement would allow simultaneous I/O dialogues and alternative switching paths in the event of switch failure. However, in many applications the potential parallel working of a cross-bar switch cannot be utilized and it is more economic in hardware to share links by time multiplexing them.

75

^t
N JN

vIN

^T

N
^

Mp

Pc-

St m -

^t
N |N

^r
N

^r
N

s
\

s
-v
N

A:
COMPUTER

^rH

v N

^r

\ r
PERIPHERALS <

L
K K

* >

Fig.6.4(a)

Input/output switching using a cross-bar or cross-point switch (PMS notation)

SOURCE 1 ( e . g . AIR DATA)

SOURCE 2 ( e . g . COMPASS)

SOURCE 3 ( e . g . DOPPLERI COMPUTER ( e . g . NAVIGATION COMPUTER)

A

K KK(BROADCAST N A V I G A T I O N OUTPUT, e.g. L A T , LONG, V E L O C I T Y ) ^ L Pc

-

Mp

Fig.6.4(b)

Data distribution by broadcast

( L A B E L STORE) M

SEQUENCE C O N T R O L L E R

PERIPHERAL SOURCES & DESTINATIONS ( I N C L U D I N G COMPUTERS)

k

DATA D ATA BUFF ER

Pc

I
Mp

Fig.6.4(c)

Data distribution organised by an autonomous controller

76

A very simple method of distributing data, which has already found wide application in avionic systems, is for a particular source of data to have a dedicated highway on which it broadcasts periodically, and in a fixed format, its data output at a refresh rate high enough to provide, for all practical purposes, continuous data (see another chapter). A computer requiring particular data "listens-in" to the appropriate highway. Such an arrangement is shown in Figure 6.4(b). A more sophisticated method is to arrange for some form of P.C.U. or autonomous controller to determine the sequence in which data from a particular source is listened to by a particular destination using a time-shared bus. Basically the controller has a local memory in which it stores the labels for the data types required in the sequence in which they are to be called. The next label is taken from memory, placed on the highway, where it is recognized by the appropriate source peripheral and any destination peripherals requiring it. In the next step the source peripheral generates the required data and the destination peripherals interested accept it. The next step is to repeat the sequence by first taking the next label from the controller's local memory. In this arrangement a processor can be joined to the highway (see Figure 6.4(c)). A development of this system is to allow peripherals to indicate when they have data ready for output by raising a common "attention" line. The controller then scans the peripherals in turn ("polls") until the demanding peripheral is detected and then serviced. Broadcast schemes may be used where relatively low data rates and response times can be tolerated. Where higher performance is required it is usual for the computer to control the input/output sequence and allocate priorities, although peripherals may be allowed to bid for service. Data messages are now not usually repeated, so that it is important to check that a message has been received correctly. In a system with a centralized computer a number of strategies for highway organization are possible. In Figure 6.5(a) each P.C.U. is connected to the I/O controller by its own dedicated highway for the transmission of control signals, addresses and data. This arrangement is termed a "starred" or "radial" highway system and is a relatively simple approach as all addressing and priority conflicts can be resolved by hardware in the I/O controller or software in the processor. Another common approach is to "bus" a single highway so that it calls in turn at each P.C.U. (is "daisy-chained") or each P.C.U. is connected to a common highway by spurs from that highway (see Figure 6.5(b)). This "bussing" minimizes system wiring, but presents difficulties when peripherals call for service simultaneously. A reasonable compromise is to star some control signals to resolve priority conflicts (Fig.6.5(c)). In determining the signal format and rates for highways it is often found that most avionic peripherals can be serviced by quite moderate capacity interfaces (typically less than 500 kilobits a second in commercial systems, and 1 megabit a second in military systems) but a minority require significantly higher information rates. One possible solution is to give the P.C.U.'s controlling such devices direct access to memory via their own ports on the memory interface. This technique is called "ported storage" and requires special logic in the interface to resolve priorities between ports. Ported storage is also used as a means of communication between processors (that is in "multiprocessor" systems). For example in Figure 6.5(d) the memory highway of each processor interfaces to a common block of memory. A further technique is to treat all external peripherals as part of the memory, all peripheral highways being multiplexed onto a memory highway (Fig.6.5(e)). A further fundamental decision is the control timing philosophy. Two basic methods are available: strobe and handshake. In the first the data together with a validating strobe or clock signal is transmitted from the source and sufficient time allowed for it to be propagated down the highway and recognized at the termination. Strict control of timing and signal overlap is required. For the handshake case, two signals (J and K) are required. The acceptor requests data with the J signal, the source indicates with the K signal that it has placed data on the highway, the acceptor removes it when it has accepted the data, and finally the source removes K when it has cleared the highway again. This handshake is not subject to timing rules and changes can be made in the length of the highway without system timing having to be modified. However, more signal transitions of the highway occur in transferring one word. Very often a system justifying a sophisticated I/O system to deal with some of its peripherals will have a number of slowly changing digital or analog signals which justify a simpler approach. A suitable approach is to multiplex such signals together and present them in the form of a sequential scan which is input on a single I/O channel. Where communication with peripherals remote from the main body of the computer system is required, some special form of link may be justified. Normally such a link will be serial in form and probably simplex, the data and clock signals being combined as a single signal, the clock signal being implied in the data signal message structure. For long distance transmission the digital signal is used to modulate a carrier suitable for transmission over land-lines and radio-links. This is known as a data-link.

77 COMPUTER
A I

S T A R R E D HIGHWAYS PERIPHERALS
-. y A . . A ,

K-

Mp

Pc

-StmI K

Fig.6.5(a)

Starred input/output highway

'DAISY CHAINED'

'SPURRED'

Mp

1
K

r~K
L

1
L 1

">

K
K

i_-

" T T

f
L

K K

T T

L ^

Fig.6.5(b)

Bussed input/output highway

Mp

-Pc

L L L L_ L
>

Data/Control Highway
K

Control Highway

Fig.6.5(c)

Starred control highway/bussed data highway

Mp

Pc-

K
>= K K

I
K

:}
T T

LOW D A T A RATE PERIPHERALS HIGH D A T A RATE PERIPHERAL WITH ESS TO MEMORY PORT ACCE

1 ?

}
Pc

STORE WITH PORTS TO BOTH PROCESSORS K

I
Mp"
s

V
-*-

Fig.6.5(d)

Uses of 'ported storage'

MpLm

LmK

Pc

Lm -Lio K T T T T Lio

high speed memory highway bussed input/output highway

I
s Lm multiplexor K Liomultiplexor

K
K K

Fig.6.5(e)

Input-output treated as extension to memory

78 All highway and link systems involve the definition of the electrical standards and codes of practice (e.g., line terminations) to be used to ensure adequate performance in the electrical environment likely to be encountered.

6.5

RELIABILITY CONSIDERATIONS

The wider application of digital computers in aerospace systems is critically dependent on the achievement of high reliability and the development of techniques to ensure that, when faults do occur, the effect on the system should not be catastrophic. Faults can occur externally to the computer system, as for example due to the failure of primary power supplies or the input of invalid data, or within the system, either due to the incorrect functioning of hardware components or errors in software programs. Initially the main effort has been directed to improving hardware reliability by good component and equipment design, supported by the development of quality assurance and reliability engineering techniques aimed at detecting and remedying weaknesses in equipment design during the development, manufacturing and in-service phases of the equipment's life. With the improvement in component technology it is becoming increasingly possible to use functional redundancy of components and equipments so that, in the event of the failure of a particular element, its role will be carried out by other elements in a manner such as to maintain system performance (see Reference 9). This philosophy is already widely applied in other aerospace disciplines, such as airframe design and hydraulic control system design. Such digital systems are said to be "fault-tolerant", the degree of fault tolerance required being derived from the target for the reliability of the system. Typically it will be necessary to define the type of fault that will be tolerated (permanent, intermittent, transient), the total number of faults, the minimum time between faults, and what degradation of system performance (both short-term and long-term) is acceptable. Software faults can arise from circumstances which have not been correctly anticipated (e.g., peak loading) or from actual errors in programming or from the input of invalid data from external sources. This latter fault gives rise to the concept of data integrity - the assurance that data, particularly that transmitted from one data area of memory to another or one system to another, is valid. The problem of comprehensively testing system software is discussed in another chapter. Fault-tolerance and data integrity can be provided by a combination of hardware and software techniques (see References 4, 5 and 6). As may be expected there is a trade-off between what is possible and what is practical. A modem real-time computer usually has a number of operating modes or levels associated with its operating system. The executive level has privileged modes of operation (e.g., access to all memory, internal status registers, etc.) and task programs, so as to restrict the interaction between such programs, and hence the propagation of faults. The operating system is designed to respond in a coordinated manner to changes in system requirements and status (including system mulfunction) which may be indicated by status words, program interrupts and data interrupts. An outline structure of a typical real-time operating system is shown in Figure 6.7, where the authority of control increases from bottom to top. Katzan 8 identifies seven main properties of an operating system, and these all warrant the attention of the system architect: Access Utilization how the user operates with a system. An avionic system is usually sensor driven, although it may involve man-machine interfaces. the manner in which the system is used. Avionic systems are normally pre-programmed although operators may call up alternative programs from a backing store if alternative or revisionary modes of working the system are required. Most avionic applications do not involve a large data-base and associated data management techniques. deals with quality of service. As the avionic system is real-time and sensor driven, the system must provide adequate response time and through-put. determines how processing time is allocated to jobs. Typically an operating system will operate on a priority basis with a number of priority queues (e.g., corresponding to data interrupts, object programs, and system test programs) with facilities to dynamically reallocate priorities according to system status. concerned with the allocation of storage to tasks. Typically storage can be allocated to tasks in blocks, the limiting addresses of which are determined by the contents of base and limit registers. Any attempt by a task program to communicate outside its allocated area will be prevented by hardware and the executive notified by interrupt. By adding additional bits to the memory word length individual words can be protected (for example a bit can be added which, if set, prevents the particular word from being over-written)

Performance

Scheduling

Storage Management

79

or checked for corruption (e.g., by the use of an odd parity bit, which is set if the number of ones in the corresponding binary word is odd). Any attempted violation of the protection, or a failure of parity checks, is detected by hardware and again notified to the supervisor by interrupt. Sharing the functional capability of the system to share program data and hardware devices. The extent to which different task programs have subroutines, common data and input/output facilities, must be decided and the appropriate facilities and software interfaces established. this is concerned with the real physical system and how it appears to the task programs. It is required to define how the system is organized and how the organization can be varied by the executive. For example, a computer may use the technique of virtual storage, where each task program is written as though it has available a continuous range of memory addresses; although the real memory of the machine is shared between all the computer programs, and the actual addresses allocated for a particular program need not be consecutive. Thus a translation is required between the virtual memory addresses, which are continuous, and the real addresses, which are not. This dynamic address translation requires special hardware facilities in the machine. It may be a requirement for it to be possible to remove dynamically a failing module from a system. One example of this is the reallocation of memory in the event of a limited memory failure by use of the base and limit registers. An extension of this idea treats all input/output as memory and defines also, by loading additional registers, the type of access that is permitted. Memory and input/output facilities can then be reallocated under executive control", although an alternative approach is to allow the registers to be controlled by a special very reliable configuration control module12.

Configuration Management

Although the above operating system properties are not exhaustive enough to automatically classify specific systems, they do form a useful basis for comparison. The techniques of function redundancy can be classified into two types: - fault masking redundancy, standby redundancy. The fault masking redundancy is achieved by implementing the function so that it is inherently error correcting. One such approach is Triple Module Redundancy (see Figure 6.6) where a function is performed by each of three identical modules working in parallel and a vote taken of the outputs, the majority signal being accepted as the true output. The level of modularity used can be from, say, logic-gate level upwards. Another approach is the use of redundant codes which allow errors, resulting for example from transmission, storage and arithmetic and logical operations, to be automatically detected and corrected. In standby redundancy the hardware system is divided into suitable modules and when a particular module is believed to be faulty it is replaced by a spare standby module. This technique therefore involves: - detection of a fault, location of a fault down to at least the replacement module level (with detection this constitutes diagnosis), - prevention of the propagation of the fault, the corruption of essential data and the output of invalid data or control signals likely to cause catastrophic effects, reconfiguration to give a working system restart from a valid state (recovery). The control of the above action may be by software or hardware or a combination of the two and the system may be self-repairing or repaired under external control. All of these functional redundancy techniques involve the use of additional hardware. In fault-masking logic this is the redundant modules, the voting logic, or the coding and decoding logic. Standby redundancy involves not only the replacement modules but also the extra equipment required to diagnose the faulty modules (e.g., BITE) and effect the necessary switching to replace it. Extra equipment involves an increased probability of component failure and increased equipment cost. Thus the design of a reliable system involves trade-offs which are extensions of the system considerations already discussed. Again a modular level of analysis is applicable, but now involves the reliability of possible modules and the corresponding additional hardware involved in the functional redundancy. The reliability of the individual modules and additional hardware can be computed from the failure rates of the basic components if these are known. Often measured failure rates for the components used under the appropriate conditions of use are not available and some acceptable set of representative figures are used as a basis of comparison. However, it must be remembered that, under these circumstances, the absolute failure rates predicted for the system may not be valid.

80

SINGLE TMR STAGE

FUNCTIONAL MODULES

VOTING LOGIC CHANNEL 1 A F A U L T

FUNCTIONAL MODULES

VOTING LOGIC CHANNEL 1 B FAULT

CHANNEL 1 TYPE A

V
\ \
y

/
^ C H A N N E L 2 A FAULT

CHANNEL 2 TYPE A

-fr
\

7x\
N
CHANNELS

CHANNEL 3 A F A U L T

TYPE A

V = two out of three voter

Fig.6.6

Triple module redundancy (TMR)

81

MACHINE BOUNDARY ALARM INTERRUPTS HARDWARE INTERFACE

EXECUTIVE

OVERRIDE

CONFIGURATION CONTROL SUPERVISOR

FAULT INDICATION STATUS PRIORITY ASSESSMENT DATA INTERRUPTS CONTROL INPUT/OUTPUT CONTROL FAULT PROCEDURES

MEMORY BASE & LIMIT REGISTERS, ACCESS REGISTERS.

TIME OUT FAILURES. FUNCTIONAL FAILURES.

f
MEMORY PROGRAM INTERRUPTS PROGRAM SELECTION (MULTI-ACTIVATION) (PRIORITY ASSESSMENT)

REAL-TIME CLOCK

CYCLIC FLAGGING

INTERLACED TEST PROGRAMS

TASK OR OBJECT PROGRAMS

FLAGS FOR SERVICE MEMORY

BASE LOAD PROGRAMS (ZERO PRIORITY) (TEST PROGRAMS)

Fig.6.7

Typical general structure of an operating system

82 Among the advantages of the masking technique is the immediacy of the corrective action, its capability of dealing with permanent and transient faults, and the relative ease of conversion of a non-redundant design to a redundant one. The disadvantages include the need to keep all the redundant units powered, the difficulty of synchronizing the clocks of parallel units, and the difficulty of pre mission check out of permanently wired units. Systems based on standby redundancy have the advantage that all the spares can be utilized (i.e., the systems will continue to operate at the simplex level), the number of spares at each stage can be optimized in terms of the reliability of the modules, only the on-line units need be powered, and the replacement switch provides fault isolation between modules. Usually with each additional failure the capability of the system is reduced, although it continues to operate in a degraded way: the so-called process of "graceful degradation". As interconnecting highways and switches may themselves fail, usually some redundant form of interconnecting highway is required, increasing the complexity of the system design considerations discussed in a previous section. Most published designs of fault-tolerant systems are based on standby redundancy, but use error detecting codes as an aid to fault location, and masking logic in the basic control equipment necessary for system reconfiguration. Significant improvement in mission reliability is only possible if the switching devices and monitors used for reconfiguration are much more reliable than the functional modules being switched. A further consideration for the system designer is the choice of memory technology. The conventional core memory is a destructively-read random access memory (R.A.M.) system. That is data in memory is destroyed during the reading operation and must be restored from external buffer store if it is to be retained. This implies that there is a possibility of information in store being corrupted by electrical interference during operation, although core memories are normally designed to minimize such occurrences and can, for example, be designed to shut-down in a safe sequence in the event of primary power supply failure. There are techniques for reading magnetic core and thin-film memories non-destructively, or alternatively hard-wiring the information into the store, to give read-only memory (R.O.M.) which can be used for essential data and program, including programs required for recovery. Similar techniques are possible with memories based on semi-conductor techniques. It is also possible to use some form of "backing store" as the source of program and initial data in a recovery process, for example to replenish a R.A.M. store which has experienced a transient fault. The "backing store" holds the data in some reasonable permanent form (for example on punched plastic tape or as digitally encoded magnetic tape). Typically such stores have relatively slow reading speed, which must be allowed for in designing the recovery sequence. The above assumes that it is economic to use immediate access memory for both program and data. In some applications (e.g., of a management type) the amount of storage required may justify the use of some form of bulk storage such as drums, discs and magnetic tape, albeit that such devices are difficult to design for use in a hostile environment. The system architect is then involved in planning a memory hierarchy and data management system. 6.6 EXAMPLES OF AVIONIC SYSTEM ARCHITECTURE Other AGARD publications have given examples of the application of computers in aerospace systems (References 12, 13 and 14) and Langley19 gives a useful review of avionic data processing requirements. A simple matrix for system classification is given in Figure 6.8, and a number of typical avionic systems have been related to it. The matrix identifies systems as being potentially capable of producing catastrophic and noncatastrophic failure modes. However, usually the effect of failures of a system are complex and lead to a spectrum of effects which can be analyzed by the Fault-Tree Analysis techniques described in another chapter. It is difficult to think of any applications of dedicated or integrated single computer systems which can cause catastrophic failure, as usually the user has required some form of manual override or reversionary mode to be possible. Interesting examples of system architecture for space applications have been described in the literature (see References 14 and 17), but understandably little information has been published relating to modern military aircraft and satellites. However it is apparent that the implementation of the avionic systems of a number of new military aircraft has been made possible by developing the system within a defined system architecture (e.g.. References 20 and 22). It is anticipated that this approach will considerably simplify the additon of new equipments or operating modes during the life of the aircraft concerned. A particularly interesting area of international activity is the development of long Range Patrol Aircraft having both a surveillance and attack role. Such aircraft typically carry a number of sensors, such as active and passive radars, infra-red scanners, and optical devices (search lights and Low-Light T.V.) for detecting air and surface targets; passive and active sonobuoys and Magnetic Anomaly Detectors (M.A.D.) for detecting sub-surface targets plus an

APPLICATION

SAFETY, MISSION SUCCESS, ESSENTIAL

DEDICATED (SPECIAL PURPOSE COMPUTER) Inertial Navigation System. Air data unit. Engine health Monitor. (Chapter 11) Head-up Display Control

INTEGRATED (CENTRAL COMPUTER) (SINGLE PROCESSOR) Navigation/Attack. Stores management. Automated ground/ air data exchange. (MULTI-PROCESSOR) Sensor processing

FEDERATED (MULTI-COMPUTER) Long range patrol aircraft system (includes sensor processing) (Ref. 21). Airborne early warning system. Area navigation.

No

Aircraft

Yes

Terrain following/ avoidance.

Stability augmentation system.

Full authority engine control. Auto landing/ Auto pilot. Space laboratory information system, (Ref. 14)

No

Inertial Reference

Satellite data handling (Ref. 15). Missile auto-pilot. Missile guidance. Spacecraft guidance (with manual reversion). (Ref. 13). Deep-space probe (Ref. 17). Launcher guidance and control (Ref. 13).

Spacecraft/ Missile

Yes

Fig.6.8 Classification of typical computer-based avionic systems

84 array of missiles, guided and conventional bombs and torpedoes for air-to-surface attacks. Given also that such patrol aircraft often operate in cooperation with other aircraft and ships and that this involves the exchange of tactical data, often automatically via data-link, it is apparent that this is an application where most aspects of computer architecture are involved. A speculative block diagram of a possible system for such a patrol aircraft is shown in Figure 6.9. An illustration of the complexity of a typical aircraft installation is provided by Figures 6.10 and 6.11. The various sub-systems are divided into Sensor, Tactical, Flight Control and Weapon areas. Several of the sensors mentioned can generate large quantities of analog and digital data (e.g., radar video) at high rates. The design of the processing of such signals involves trade-offs between processing methods (e.g., the use of analog, special-purpose and general-purpose processors) and a choice of ways of spreading the processing loads (e.g., using a central high-power processor or a number of lower-powered processors). The strategy is to attempt to confine the high-rate signals to the sensorprocessing areas and to spread the computing load by using buffer-storage and ported-storage techniques. The objective of the sensor processing during the surveillance role is to present essential target and other data to the tactical system so that information can be correlated and compiled into a tactical picture which a human operator can use to make tactical decisions and initiate or control any subsequent attack phase. The signals transmitted to and from the tactical sub-system are relative low rate signals (e.g., target classification and position) which can be handled by bussed serial highways and serial data-links. The assessment of the tactical situation involves threat evaluation, engageability assessment and the allocation of weapons to targets, and such decisions can be computer aided. The final attack phase involves the check-out, initialization, firing and guidance of weapons, perhaps via a "stores management" sub-system, and possibly the control of the aircraft flight path either directly via the autopilot or indirectly by displaying "director" signals to the air crew. In the diagram a number of signals between the flying controls and the control surface actuators are shown as being digital. This assumes a "fly-by-wire" philosophy which has yet to gain general acceptance. Chapter 8 surveys the total systems and computer architecture considerations involved in a specific application: the control of jet engines. This is an interesting application inasmuch as it is proving difficult to get digital techniques accepted for full-authority control even though experimental digital systems have been successfully demonstrated. It is a typical case of replacing an established and proved technique (namely hydro-mechanical and electrical control) when aircraft safety is directly involved.

REFERENCES
1. Bell, C. et al. 2. Knight, Kenneth,E. 3. Malach, E.G. 4. Avizienis, Algirdas 5. Carter, W.C. Bouricius, W.G. 6. Elspas, Bernard et al. 7. Cochran, W.T. et al. 8. Karzan, Harry 9. Von Alven, William H. et al. 10. Williams, R.K.. 11. Crapnell, L.A. Computer Structures: Readings and Examples, McGraw-Hill Book Co., New York, 1971. Changes in Computer Performance, Datamation, Vol.12, No.9, pp. 40-54, September 1956. Job-Mix Modelling and System Analysis of an Aerospace Multiprocessor, IEEE Trans, on Computers, Vol. C-21, No.5, pp. 446-454, May 1972. Fault Tolerant Computing, an Overview, Computer, Vol.4 No.l, pp.5-8, January/ February 1971. A Survey of Fault-Tolerant Architecture and its Evaluation, Computer, Vol.4, No.l, pp. 9-16, January/February 1971. Software Reliability, Computer, Vol.4, No.l, pp. 21-27, January/February 1971. What is the Fast Fourier Transform? IEE Trans, on Audio and Electroacoustics, Vol. AU-15, No.2, pp. 45-55, June 1967. Operating Systems Architecture, AFIPS Conference Proceedings, Vol.36, pp. 109-117, May 1970. Reliability Engineering, Prentice-Hall Inc., New Jersey, 1964. System 250 - Basic Concepts, Conference on Computers, Systems and Technology, IERE Conference Proceedings No.25, pp. 157-168, October 1972. An Economic Architecture for Fault Tolerant Real Time Computer Systems, Conference on Computers, Systems and Technology, IERE Conference Proceedings, No.25, pp. 119-130, October 1972.

B S 12. Leondes, C.T. et al. 13. Miller, J.E. et al. 14. Keonjian, E. et al. 15. Remmington, J.E. et al. Computers in the Guidance and Control of Aerospace Vehicles, AGARDograph No.158, February 1972. Space Navigation Guidance and Control, AGARDograph No. 105, 1966.

Automation in Manned Aerospace Systems, AGARD Conference Pre-Print No.l 14, October 1972. An Outline of the Ferranti Data Handling System Proposed by the Sud-Aviation Group for Project L.A.S., Conference on Aerospace Computers in Rockets and Spacecraft, C.N.E.S. Paris, December 1968. Special Issue on Fault Tolerant Computing, IEEE Trans, on Computers, Vol. C-20, No.22, November 1971. A Fault Tolerant Information Processing System for Space Vehicles, IEEE Trans, on Computers, Vol.C-20, N o . l l , pp. 1394-1403, November 1971. Introduction to Programming and Computer Science, McGraw-Hill Book Co., New York, 1971. A Universal Function Unit for Avionic and Missile Systems, Proceedings of the National Aerospace Electronics Conference, pp. 178-185. published by the IEEE, New York, 1971. BI - Avionics are Geared to Operational, Growth Needs, Aviation Week and Space Technology, pp. 52-54, April 23rd 1973. Advanced ASW Gear, Space Economy Mark Design of S-3A, Aviation Week and Space Technology, pp. 95-107, September 15th 1969. AWACS Uses Flexible Computer, Aviation Week and Space Technology, pp. 106-109, September 11, 1972.

16. Ramamoorthy, C.V. et al. 17. Hopkins, Albert L.

18. Rolston, Anthony

19. Langley, Frank J.

20. Elson, Benjamin E.

21.

PlattnerC.M.

22. Elson, Benjamin E.

EXTERNAL ENVIRONMENT

SENSOR SUBSYSTEMS

TACTICAL SUBSYSTEMS OPERATOFTS\ DISPLAYS* I TACTICAL CONTROLS I CONTROLLER

AIR SURFACE SUB-SURFACE

FLOATING ACOUSTIC SENSORS ISONOBUOYSI (Passive - e g DIFAR) (Active - e g CASSI

OPERATOR'S D I S P L A Y S * \ WEAPON CONTROLS I CONTROLLER

RADIO AIDS (eg Beacons. OMEGA. LORAN DECCA. etc.l CO OPERATING FORCES

KEVa_fe______ y ^ it Analogue signal path High data-rate digital signals Low data-ratt digital signals Possible digital computer application

FLIGHT CONTROL SUB SYSTEMS

WEAPONS SUB SYSTEMS

Fig.6.9

Block diagram of a typical avionics system for a military long range patrol aircraft

87

Fig.6.10

An example of modem avionics system installation in a patrol aircraft

Fig.6.11

View of modules of avionic equipment installed in bays of patrol aircraft

88

CHAPTER 7 DEFINING THE PROBLEM AND SPECIFYING THE REQUIREMENT S.Boesso and R.Gamberale 7.1 INTRODUCTION The definition of the computer characteristics is largely an iterative cut-and-try process, where sets of often conflicting parameters have to be chosen in order to satisfy the requirements at the minimum possible overall cost. The primary requirements to be satisfied are functional, i.e., concern the capability of the computer to perform the tasks assigned to it within the available time. Other essential requirements are physical, as the computer must be able to operate properly in a certain environment with acceptable reliability and maintainability and its weight, volume and power consumption cannot exceed certain limits. The present Chapter will deal only with the functional requirements and will aim at the definition of a methodology for deriving them from the knowledge of the tasks to be performed. The considerations presented may be applied both to determine the suitability of a certain computer architecture and to compare different computers against a given application. In any case, it should be kept in mind that no computer can be judged as adequate or inadequate for itself, but only with reference to a well-defined job that it would have to handle. Therefore it is necessary that the job, or mission, be clearly described not only quantitatively, but also in terms which are desired of the computer and which allow the adequacy of a chosen architecture to be verified. The treatment will start with a brief survey of typical tasks of an avionic system, from which a sample will be picked up to be further analyzed as an example. System functions will then be introduced, to arrive at defining what the computer is expected to do. Finally, the computer tasks will be analyzed, also with the aid of examples, in order to show how the computer requirements can be arrived at. 7.2 SURVEY OF TYPICAL TASKS OF AN AVIONIC SYSTEM Avionics systems of today's aircraft are intended to perform, or to aid the crew in performing, a multitude of tasks. Some of them (e.g., stores management) are peculiar to combat aircraft, other ones (like navigation) are common to the military and to the civil sides of aviation. Typical tasks have been identified and will be concisely recalled here. The definitions given in the foregoing text, although not pretending to be standard, are considered to be general enough to cover variations which may be encountered in individual real cases. Navigation and Guidance This is defined as the determination of: present position of the aircraft with respect to the earth, by processing sensor data, course and distance from present position to selected destination points (steering information). These parameters will normally have to be displayed to the crew, which in turn will have a means of introducing position corrections in the computation, when the aircraft is flying over a known reference point. This latter action

89 is called "position fixing" and consists of the identification of reference points (on a map display and on the terrain), determination of displacement between computed and actual position and relative correction of the navigational computation. Fuel Management This task consists of the calculation and display of: Fuel remaining, Maximum range Endurance at present flight conditions

- Optimum range or optimum endurance with related required flight conditions. Engine Control The avionic system has to monitor and precisely control engine performance under the actual flight conditions encountered, i.e., Receive signals, from airframe and engine, that indicate present operating parameters, Store these data and compare actual performance with stored data indicating desired performance under given flight conditions, Drive electromechanical devices to modify fuel flow or engine geometry to attain desired performance. Stores Management The "stores" are the missiles, rockets, and bombs carried by attack aircraft either under their fuselage or wings or in the weapons bay. For this task, the computer-based avionic system has to carry out calculation and display for the following actions: Selection of weapon stations (missiles and/or bombs), Weapon fusing, Weapon release (in proper sequence), Safety interlocks for weapons, Provide information and number and distribution of remaining stores, Indicate failure of a bomb or a missile to release. Weapon Management (Air-to-Air Combat) The weapons are in this case the aircraft guns and the air-to-air missiles carried on board. The avionic system, which is a key aid for the pilot to hit the target, has to: Calculate range rate and rate of turn of aircraft, Calculate lead angles to displace target marker, Indicate to the pilot that the target is at a suitable range, Generate release instructions for air-to-air missiles or for the guns. Air-to-Ground Attack This task precedes, in time, the stores management, and consists mainly of: Target Acquisition (like steering for navigation), Target Tracking (inclusive of aircraft steering), Ballistic calculation for each type of weapon chosen and generation of weapon release information.

7.3

FROM OPERATIONAL REQUIREMENTS TO SYSTEM FUNCTIONS

An examination, with engineer's eye, of the tasks described in the preceding section shows that the avionic system has to perform a few fundamental, clearly identifiable, functions which apply, more or less, to all tasks.

90

First of all, the system will have to acquire information from the outer world or from the crew: for example, flight conditions, operator requests, engine parameters, radar range, etc. Such data are normally supplied by suitable sensors (of pressure, speed, acceleration, temperature, etc.), converted into digital form, distributed and processed as needed. The results of the processing are utilized to produce commands (for modifying the flight conditions, for firing weapons, etc.) or are displayed to the crew to help them take decisions on the mission. A number of data, either raw or processed, are stored, to be utilized at a later time, either in flight or on the ground. Finally, the key parameters of the on-board systems (air-frame, engines, avionics, weapons) have to be continuously monitored, in order to reveal incoming malfunctions and allow corrective actions to be taken, either automatically or by the crew. The following fundamental functions may thus be identified, (a) Data Acquisition Collection, conversion, formatting of sensor-generated data in order to allow their subsequent processing, Collection of commands generated by the crew. (b) Processing Application of mathematical and logical algorithms on collected data, in order to extract information and commands required for the mission. Interpretation of new commands and execution of related actions. (c) Data and Command Distribution Distribution of data and commands, resulting from processing, to on-board users (i.e., actuators of the guidance system, of the weapons, etc.). (d) Data Storage Storage of mission parameters, introduced either on the ground before flight or in flight via a telecommunication link. Recording of information collected in flight. (e) Data Display Display to the operator in different forms of data obtained as results of processing (tabular, alphanumeric, moving map, head up, synthetic-on-radar PPI, etc.). (0 Communication Transmission and reception of information from ground or other aircraft or satellites. (g) Housekeeping and Check-out Monitoring of subsystems status during operation to detect possible faults. Fault localization and redundancy switchover. Evaluation of the ability of sub-systems to perform their functions under all operational conditions, by simulation of the latter by means of proper stimuli. The diagram of Figure 7.1 shows the relationships among the functions just described. The preceding definitions are merely a properly grouped list of "actions" that the system is required to perform to fulfill its role. As such they do not mention what "black boxes" will be needed on-board to implement the system functions properly. Some idea of the hardware is, however, already present. To begin with, let us take data acquisition: part of this function, which includes Analog-to-Digital conversion of sensor data (as described in detail in Chapter 6) is normally performed by dedicated hardware, which ouputs information in a form suitable for being assimilated by a digital computer. Display and interface with operators is also performed mainly by dedicated hardware: normally a mix of electronic and optical devices which translate digital information into letters, symbols, etc. The main point is thus the definition of what are the system functions that the computer has to perform, interfacing with peripherals which supply it with properly coded digital data, or which translate its output into
f o r m s n s p a h l p PICPU/V***!-^

STORAGE
jX Ji
_l

I/)

o oo
z LU
OO

cc

t *

DATA ACQUISITION
1f
p

o COMMUNICATION

cc en

u. < c a. o
on l-H
'

PROCESSING
_x

1- oo
l_l_ UJ

<
oo
cm

<C 1 cc M o _i
Qi _ l l U J

o 11

A A
I
f l

<c Z3

DATA & COMMAND DISTRIBUTION

'

<_ I "
CC 00 UJ _H Q

< _

o <

I __r o <c

DISPLAY AND MANUAL INTERVENTION

CREW
Fig.7.1 Functional diagram of a typical computer-based avionic system

92

From the computer's point of view, all these system functions may be reduced to two main categories: Exchange of data with the "external world", i.e.. Input or Output, Processing, which takes place within the machine and accounts also for storage and internal data transfer. Let us now make an example, which will be gradually developed throughout this and the following sections to show the application of the concepts presented. Our example task is a simplified form of navigation, where the avionic system has to inform the crew of the present position coordinates and computer course and distance to a destination, starting from the present position. Let us assume that the aircraft has a Doppler Radar and a magnetic compass. The operational requirements may thus be synthesized as follows: Compute and Display to the crew the coordinates of the present position, by suitably processing ground velocity vector, as supplied by the Doppler Radar and heading, as supplied by the magnetic compass. Compute and Display, upon request by the crew, course and distance to a preselected destination point. The preceding requirements have to be translated into a list of system functions, part to be committed to dedicated hardware and part to be handled by the on-board computer(s). The avionic system will: (1) Collect and digitize speed data from Doppler Radar. (2) Collect and digitize heading data from magnetic compass. (3) Collect operator requests, from operator's panel. (4) Process collected data to obtain desired information: present latitude and longitude, course and distance to destination. (5) Display position, course and distance information to the on-board crew. As already said, fortunately for the computer designer, not all the preceding functions pertain to the computer. This latter will; (1) Input digitized speed and heading at predetermined time intervals. (2) Input destination coordinates from operator panel, upon request by the crew. (3) Process speed and heading to obtain latitude and longitude of present position. (4) Process destination coordinates to obtain (or update) course and distance. (5) Output latitude and longitude, in digital form, to display. (6) Output course and distance, in digital form, to display. The preceding procedure is to be repeated for the other tasks, to arrive at an overall definition of the computer system functions. These functions will, in turn, have to be translated into computer requirements, as described in the following section. 7.4 FROM SYSTEM FUNCTION TO COMPUTER REQUIREMENTS 7.4.1 Presentation of the Requirements

As stated in the Introduction, the present Chapter aims at describing a methodology for specifying the main functional requirements for the on-board computer, i.e., (a) for the Central Processing Unit (CPU) (1) (2) (3) (4) (5) (6) Instruction set and execution times, Instruction and data word length and format, Addressing techniques, Sub-program linkages, Interrupt techniques, Local storage.

93

(b)

for the Memory (1) Word length, (2) (3) Capacity, Cycle time.

(c)

Input/Output (1) (2) Number and type of channels, Transfer time (related to the types of channel).

Other considerations concerning self-check and repair capability and memory protection are outside the scope of this Chapter. It has to be pointed out that the method does not yield a direct and univocal solution of the problem "Given a set of tasks find out the right computer", but it rather allows the computer requirements to be arrived at after a somewhat recursive and indirect procedure. Once the tasks have been defined and quantized, limit values are derived for a number of computer parameters. Preliminary computer characteristics are then assumed and (provided no mutual incompatibilities exist), these are checked against the tasks. Usually more than one architecture may be found which satisfies the functional requirements; the best in terms of cost-effectiveness will have to be chosen. A flow-chart of this process is shown in Figure 7.2. The single steps of it will be explained with some detail with the aid of examples. 7.4.2 An Example Set of Elementary Operations

The set of elementary operations which is an application of the reverse Polish notation (so called after the Polish mathematician Lukasiewicz) is intended to serve as an example. Other sets might be chosen; the methodology would only be affected in detail, but its general lines would not change. The set is not a formally complete language, as some operations comprise classes of instructions, which, though different, would require the same computing capacity. For example, all N-place shift instmctions are covered by a single operation (N$), irrespective of their type: left, right, logical, algebraic, rotate, etc. The foregoing application of the language in our example is assumed to be performed by hand; many steps, however, may conceivably be mechanized by letting a computer perform them. The elements of the language Symbols The smallest language element is called a symbol. In our case, the symbols are all the capital letters of the English alphabet, the decimal figures from 0 to 9, the decimal point, plus the following special ones;

+ -*:,&!?%=<>"/(
Operands One or more contiguous alphanumeric symbols, written from left to right, form an operand, that is the name of a datum which is to be operated upon. For example: ABC4. If, however, an operand consists of only numeric figures and decimal point, its name is to be interpreted as its value in decimal notation; negative numbers begin with the letter N , positive numbers are not preceded by any sign. There is no limit to the number of symbols in an operand, but it is convenient to limit it to a few to save writing effort and ease mechanization. A particular operand is the "flag", which can assume only two values, 0 and 1, and is commonly used as a program switch. Flags will be indicated as FLAGJ for easy identification; J is the flag reference number. Operators An operator is indicated by one of the special symbols presented and explained in Table 7.1. Operators are applied to one, two, or three operands, as follows:

94

START
r

FUNCTIONAL ANALYSIS (MATCHEMATIC & LOGIC MODEL & DATA DESIGN)

>

TRANSLATION OF MODEL (INTO SEQUENCES OF ELEMENTARY OPERATIONS)

LANGUAGE (SET OF ELEMENTARY OPERATIONS)

j'

MEMORY FOR DATA

MISSION STATISTICS (RECURRENCE OF EACH OPERATION IN THE MISSION

fe

INPUT/OUT AND PROGRAM INTERRUPTS

r 3

INSTRUCTION WORD LENGTH AND FORMAT

EXECUTION TIMES AND INSTRUCTION SET

i'

MEMORY FOR PROGRAM

i
TOTAL MEMORY
Wi

^ACCE

\
PTABLES

N O

YES
COMPUTER REQUIREMENTS
Fig.7.2 Methodology flow diagram

95

One-operand operators: Two-operand operators: Three-operand operators:

,!"$ +*:&' = > < ?

One operator applies always to the operands that precedes it (one, two or three, depending on the operator class). Macro-operators A macro-operator corresponds to a more or less complex function, which cannot be expressed by means of one of the operator symbols already presented. TABLE 7.1 Elementary Operations Operation
y

Description Duplicate (repeat) last operand in the sequence Complement preceding operand, bit by bit Add Subtract Multiply Divide And The last six operations are performed between the last two operands in the sequence (either retrieved from the memory or obtained as a result of an operation). The result is left in the sequence as an operand that replaces the two operated upon.

Examples (4)

+
* &

(2)

(3)

M, M"

Read operand M from Memory and put it in the sequence. Read operand M from Memory and complement it, bit by bit Add M, read from Memory Subtract M, read from Memory Divide by M, read from Memory Logical AND, bit by bit, with M, read from Memory Logical OR, bit by bit, with M, read from Memory The last six operations apply to M and to the last operand in the sequence; the result replaces both operands in the sequence. For M if there is no preceding operand, the two's complement of M is put into the sequence. Store preceding operand into Memory, at location labelled X. Shift the last operand in the sequence N places, left or right, i.e., multiply or divide by 2 N . Call Subroutine M. This operation includes saving the Program Counter at the beginning of the subroutine and restoring it at the end. A particular case of a subroutine call is a macro-operator. Unconditionally jump to location M. A> B Jump to location M if A < B

(4)

M+
MM: M& M"

(1)

X= N$ M%

(1) (6) (5)

M! M> M<

(7)

(Table 7.1 continued)

96

TABLE 7.1 (continued)

Operation M? Description A = B where A and B are the operands preceding M in the sequence. If there is only one operand (viz. A) they mean respectively A> 0 Jump to M if A< 0 A= 0 Input datum from channel No. N (integer), put it in the sequence and treat it as an operand. Output to channel No. N (integer) preceding operand in the sequence. Examples

(8)

Input N, Output N=

A macro-operator is represented as a sequence of alphanumeric symbols, always followed by the special symbol %. A macro-operator can be implemented either by software as a subroutine (which would begin at memory location labelled with the macro-operator's name) or by hardware as a special instruction. In the former case, the symbol % implies therefore a "subroutine call", with related instructions which release the control to the routine being called and return the control to the calling process at the end of the routine itself. In the latter case, the symbol % is a reminder that the preceding alphanumeric symbols are not an operand, but an operator, and implies the instruction fetch from memory. Choice of either solution for each macro-operator will be made considering its recurrence frequency in the mission, as will be said later. Different choices will yield different macro-operator execution time. A macro-operator must be always preceded by the operand(s) to which it applies. Indices These are operand (address) modifiers which are appended to particular operands (e.g., n th element of a data table) separated by an open parenthesis. Operands followed by one or more indices are treated by operators like simple operands. Indices pertaining to the same operand are separated by a slash, e.g., A(J/K. Table x.x.x summarizes some of the most frequent cases. Elementary operations An elementary operation is the application of an operator to one or more operands. It is indicated either by an operand followed by an operator symbol (e.g., M+) or simply by an operator, which in this case refers to the preceding operands; these latter are in turn results of other operations. Table x.x.x shows the elementary operations and gives reference to a number of examples. Statements A sequence of elementary operations and macro-operators which describe a sequence of actions encountered in the system task, constitutes a statement. A statement must always begin with a new line and with the first symbol of an operand. It may extend over more lines, each line ending with an operator symbol, and it must end with one of the following operators: = < > ? ! . Some statements may be numbered or labelled, for the analyst's convenience. Their label or number will be written at the extreme left of the first statement line, separated from it by a few blanks. For example: FORM A,B + C : Z =

which means that the statement labelled FORM is (A+B) : C = Z .

i>7

TABLE 7.2 Indices Diagram of Operation Mnemonic Description Memory Address Memory Contents -Operand A I A+I A I A+I
Y
ir

A A(I

no index one-entry array

Operand

A(I/J

two-entry array

Y+J A(I/J/K three-entry array A i A+I Y i Y+J

Z
ir

-Operand

-Z

Z+K

Operand

It can be noted that, in the Reverse Polish notation, operands and operators generally appear in a statement in the same sequence in which the operands would be called in a computer and the operations performed upon them. Short examples are referenced in Table 7.1 to help the reader in understanding. More complex examples follow separately. Examples (1) X = A 'op' B where 'op' is one of the operators + * : 'and' 'or' is translated into: A,B 'op' X = which indicates the following sequence of operations: A, B 'op' X= Read operand A from Memory and put it in the sequence, Perform the operation 'op' between operand B, retrieved from Memory and operand A, Store the result into the Memory location labelled X.

(2) X = (A+B)'op'(CD) where'op'can be one of the operators + -* : is translated into: A,B+C,D+ 'op' X= which indicates the following sequence of operations:

98

A, B+ C, D+ 'op' X=

Read A from Memory Add B, read from Memory, to A Read C from Memory Add B, read from Memory, to C Perform the operation 'op' between the two preceding operands, i.e., (A+B) and (C+D) Store result into Memory location X.

(3) X = (A and B) 'op' (C and B) where 'op' can be one of the operators 'and", 'or, and the line over the expression indicates the operator 'not' is translated into A,B&C,D+'op'"X= which indicates the sequence of operations: A, B& C, D& 'op' X Read A from Memory Perform logical 'and' between B, read from Memory, and A Read C from Memory Perform logical 'and' between D, read from Memory, and C Perform operation 'op' between the two preceding operands, i.e., (A and B) and (C and D) Complement result of 'op', bit by bit Store result into Memory location X.

(4) X=(A+B)2 is translated into A,B+,*X= which indicates the sequence of operations: A, B+ * X= Read A from Memory Add B, read from Memory, to A Repeat (A+B) Multiply the two preceding operands, i.e., (A+B) by (A+B) Store result into Memory location X.

(5) X= Log(SIN)A+B)--3S)+C is translated into: A,B+ NO.35, EXP% SIN% LOG% C+X= which indicates the following sequence of operations: A, B+ NO. 35 EXP% SIN% LOG% C+ X= Read A from Memory Add B, read from Memory, to A Read -0.35 from Memory Call macro-operator EXP, which applies exponent 0.35 to operand (A+B) Call macro-operator SIN, which computes sine of preceding operand, i.e., of (A+B)-0-35 Call macro-operator LOG, which computes decimal logarithm of preceding operand, i.e., SIN(A+B)--3S Add C, read from Memory, to preceding operand, i.e., to LOG(SIN(A+B)-<)-3s) Store result into memory location X.

99

(6) Extraction of a field (FIELD) from a word (WRD) using a mask (MASK) WRD FIELD i and 0 0 11 0

N bits

MASK

right shift, N bits result X= FIELD

The operation is described by the following sentence: WRD.MASK & N$ X= where N$ indicates the shift operation. It is not important to specify the direction of the shift for the purpose of the analysis. The evolution of the recurrence of the shift operation will give an indication on the required speed and, indirectly, on the shift implementation (one bit, two-bits, or multiple bits at a time). (7) Logical IF (see FORTRAN) IF (A.EQ.B) GO TO 3 translates into IF (A.NE.B) TO TO 3 translates into IF IF IF IF IF (A.GT.B) TO TO 3 translates into (A.LT.B) GO TO 3 translates into (A.GE.B) GO TO 3 translate into (A.LE.B) GO TO 3 tranlates into (A.GT.B.OR.C.LT.D) GO TO 3 translates into IF (A.GT.B.AND.C.LT.D) GO TO 3 translates into A,B,3 ? A,B,CONT?3! (where CONT indicates the following statement) A,B,3> A,B,3A A,B,3>3? A,B,3A3? A,B,3>C,D,3< A,B,X>CONT! X C,D,3< CONT where X is the label of the statement corresponding to the second condition and CONT is the label of the statement to be executed if neither condition is satisfied.

(8) Arithmetic IF (see FORTRAN) IF (arithmetic expression) ml,m2,m3 e.g.: IF (A-B) 1,2,3 is translated as: A.B-K2? 3> 7.4.3 Functional Analysis

All the functions defined under the heading "Processing" in "From Operational Requirements to System Functions" which are to be implemented by the computer (hardware + software), are analyzed in order to arrive at an acceptable mathematical and logical model. This analysis will produce: - algebraic and logical procedures on data, - design design: definition of variable and constant data to be operated upon, with specifications of their resolution and range, - program organization: sequencing and timing of programs, logical procedures for control.

100

A flow diagram describing the overall functional organization and algorithms is drawn (Fig.7.3). Data are listed in tables like Table 7.3 and Table 7.4 including: mnemonic label, number of bits, and a brief but clear description. Let us recall the navigation example task introduced in the preceding section, and, as it implies two different computing sequences, let us split it into two example tasks which will be called Task 1 (Dead Reckoning) and Task 2 (computation of great-circle course and distance). Example Task 1 - Dead Reckoning (from Doppler Radar). The flow-chart is shown in Figure 7.3. Let us also assume that the task is repeated once every 0.05 seconds. The exact formulas for the computation would be: LAP = LAI + K f VG . COSHG dT

I
HG where LAP, LOP, HG, VA, HDR, VG, T, LAI, LOI, K, HC, present latitude present longitude ground track magnetic variation drift angle (from Doppler Radar) ground speed (from Doppler Radar) time initial latitude initial longitude earth's curvature parameter magnetic heading (from magnetic compass) = HC + VA + HDR

SIN HG COS LAP

dT

A digital computer, however, cannot integrate continuous quantities. For this reason, the integrals of the exact formulas are replaced by sums, to yield trapezoidal approximate integrations, as follows:

LAP = LAO + KT* (VGP* COSHGP + VGO* COSHGO) & DT LOP = LOO + KT* (VGP* SINHGP : COSLAP + VGO* SINGO : COSLAO)* DT HGP = HCP + VAP + HDRP.
Suffixes P and O indicating present data and old data respectively, KT = K/2. The meaning of each variable is explained in Table 7.4.3.1; the number of bits is symbolically indicated, as actual values depend on the particular application. Example Task 2 Computation of Great Circle Course and Distance from present point P to point Dj (one out of a few possible destinations). Repeated once per second. The flow-chart is shown in Figure 7.4. The applicable mathematical formulas are the following: (a) Great Circle Course formula HCGj = ARCTAN(COSLADi*SIN(LODi-LOP):(COSLAP*SINLADi-SINLAP*COSLADi* *COS(LODj-LOP)).

(b) Great Circle Distance formula DGCj = ARCSIN(COSHGCi*(COSLAP*SINLADi-SINLAP*COSLADi*COS(LODi-LOP)) + (SINHGCi*COSLADi*SIN(LODi - LOP)) where: HCGj, DGCj, LADj, Great Circle Course to point Dj Great Circle Distance to point D-, Latitude of Dj LODit Longitude of Dj LAP and LOP have been computed in the preceding Task 1.

101

DEAD RECKONING

INPUT PRESENT GROUND SPEED & DRIFT ANGLE

INPUT PRESENT MAGNETIC HEADING

YES
INPUT MAGNETIC VARIATION FROM OPERATOR PANEL

COMPUTE GROUND TRACK HG

COMPUTE AND STORE SIN HG AND COS HG

COMPUTE PRESENT LATITUDE AND REPLACE OLD VALUE

COMPUTE PRESENT LONGITUDE AND REPLACE OLD VALUE

EQUAL PREVIOUS LATITUDE TO PREVIOUS LATITUDE

EQUAL PREVIOUS VG, HG, SINHG, COSHG, COSLA, TO PRESENT VALUES

YES

OUTPUT PRESENT LATITUDE AND LONGITUDE

/RETURN A-

Fig.7.3

Task I flow diagram

102

INPUT DESTINATION NUMBER FROM OPERATOR PANEL

YES

NO
REQUEST DATA FROM OPERATOR

INPUT LATITUDE (LADi) AND LONGITUDE (LOD-j) FROM OPERATOR PANEL

COMPUTE GREAT CIRCLE COURSE HCGi FROM DESTINATION COORD. (LADi, LOD-j) AND FROM PRESENT POINT COORDINATES (LAP,LOP)

COMPUTE GREAT CIRCLE DISTANCE DGCi FROM GREAT CIRCLE COURSE, DESTINATION COORDINATES AND PRESENT POINT COORDINATES

OUTPUT AND STORE HGC, AND DGC.

YES

Fig.7.4

Task 2 flow diagram

103

The same data are presented in Table 7.4, using the rules for indices. 7.4.4 Translation of the Model

Once the overall mission has been described as in the preceding section, it has to be "translated" into a list of statements making use of the elementary operations, in order to arrive at the mission statistics (i.e., type and frequency of each elementary operation). The translation process will be explained with the aid of the two example tasks already presented. The reader will also have to make reference to Tables 7.1 and 7.2. Each task is assumed to be activated by a program interrupt, which is treated like a macro-operator. Example Task 1: Dead Reckoning

INTNAV

INTDEAD% INPUT 1 , VGP= INPUT 2, HDRP= INPUT 3, HCP= FLAG 1,0.OPER ?

Call of DEAD task

Is old value of VAP STILL VALID?

OPER

END where INPUT 1 INPUT 2 INPUT 3 INPUT 4 OUTPUT 1 OUTPUT 2

INPUT 4, VAP= HCP, VAP+HDRP+HGP= HGP,SIN%SHGP= HGP,COS% CHGP= VGP,CHGP* VGO, CHGO*+KT+DT+LAO+LAP= LAP,COS% CLAP= VGP,SHGP*CLAP : VGO,SHG)*CLAO: +KT*DT* LOO+LOP= LAP,LAO= LOP,LOO= HGP,HGO= SHGP,SHGO= CHGP,CHGO= CLAP,CLAO= FLAG2,0,END ? LAP.OUTPUT 1 = LOP.OUTPUT 2= return to the calling program (included in % operator).

is the channel providing VGP is the channel providing HDRP is the channel providing HCP is the channel providing VAP is the output channel for LAP. is the output channel for LAP.

104

TABLE 7.3 Task 1 Data Definition

Mnemonic LAP LAO KT VGP HGP VGO HGO DT LOP LOO HCP VAP HDRP

No. of Bits nl nl n2 n3 n4 n3 n4 n5 nl nl n4 n4 n4 Present latitude Old latitude

Description

= k/2, where K is the earth's curvature parameter Present ground speed Present ground track Old ground speed Old ground track Time increment Present longitude Old longitude Present magnetic heading Present magnetic variation Present drift angle

TABLE 7.4 Task 2 Data Definition

Mnemonic HCG(I HGC(I LAD(I LOD(I LAP LOP

No. of Bits n6 n7 nl nl nl nl

Description Great Circle Course to point Dj Great Circle distance to point Dj Latitude of point Dj Longitude of point Dj Present latitude Present longitude from Task 1

It can also be noted that, in writing the statements, we have introduced for convenience a number of intermediate variables, which will have to be stored into memory places. These variables will be listed, for each task, in tables like those described in the preceding section, and taken into account when estimating the size and organization of the data memory (as described later). For this example the intermediate variables are shown in Table 7.5. TABLE 7.5 Task 1, Intermediate Variables

Mnemonic FLAG1 SHGP CHGP CHGO CLAP CLAO FLAG2

No of Bits
1 ml ml ml ml ml 1

Description Flag indicating the availability of a new VAP sinHGP cosHGP cosHGO cos LAP cos LAO Flag indicating that an output is requested.

105 Example Task 2: Great Circle Course and Distance GREAT Call of GREAT task INTGREAT% INPUT 4,1= FLAG3,1,CALL? Are coordinates in memory? REQ,OUTPUT3= Output coordinate request INPUTS,LAD(I= INPUT6,LOD(I= LAD(I,COS%CLAD(I= LAD(I,SIN%SLAD(I= LAP,SIN%SLAP= LOD(I,LOP-COS%CLDP(I= LOD(I,LOP-SIN%SLDP(I= CLAD(I,SLDP(I*CLAP,SLAD(I*SLAP,CLAD(I*CLADP(I*-:ARCTAN%HGC(I= HGC(I,COS%CLAP,SLAD(I*SLAP,CLAD(I*CLDP(I*-* HGC(I,SIN%CLAD(I*SLDP(PV+ARCSIN%DGC(I= DGC(I,OUTPUT4= HDG(I,OUTPUT5= INFLAG7.1,GREAT ? Are there other operator requests?

CALL

where INPUT4 INPUTS INPUT6 OUTPUT4 OUTPUTS is the is the is the is the is the channel providing the destination number I channel providing the latitude of destination I, unless already in memory channel providing the longitude of destination I, unless already in memory output channel for DGC(I output channel for HGC(I

The intermediate variables are shown in Table 7.6. TABLE 7.6 Task 2, Intermediate Variables Mnemonic FLAG3 REQ CLDP(I SLDP(I CLAD(I SLAD(I SLAP INFLAG7 7.4.5 Mission Statistics No. of Bits 1 m3 m4 m4 m5 m5 m6 1 Description Flag indicating that the coordinates of destination I are in memory Request message cos LDP(I sin LDP(I when I = 1, . . . . N (N words) cos LAD(I sin LAD(I sin LAP Flag indicating an operator request

Once the translation of the tasks into elementary operations has been accomplished, the recurrence frequency of each elementary operation can be calculated for each task and for the whole mission. This process will be called "Mission statistics" and is conveniently performed in two steps. In the first step the elementary operation (Table 7.7) and the macro-operations (Table 7.8) for each task are counted. This first count will be needed for defining program size and related memory requirements. In the second step, the operation distribution of each task is multiplied by its recurrence frequency in the task (Table 7.9) and the same procedure is applied to the macro-operations (Table 7.10). This second step defines the "mission spectrum", which will be used to arrive at defining the instruction set. The machine registers have to be also counted, i.e., those temporary storage devices for intermediate results or operands which will be needed more

106

TABLE 7.7 Operations Distribution

Tasks
^ ^

^ y
Operations *

2 1 : 10 12

&

II

M, 20

M+ 4

M-

M* 8

M: 2

M&

M-

X= 18 10

I. Dead Reckoning 2. Great Circle 3. Other Tasks TOTAL 150 150

1 130 131

1 50 51 10 10 10 10 10 10

17 550 587 500 504

2 80 82

9 280 297 150 152 20 20 10 10

220 223

400 428

Tasks

^ y

NS

M%

Ml

M<

M>

M?

M"

1NPUTN, OUTPUTN=

(1

(l/J

^yOperations 1. Dead Reckoning 2. Great Circle 3. Other Tasks TOTAL 300 300 1 10 50 64 1 1 100 102 100 100 100 100 2 1 90 93 10 10 4 3 50 57 2 2 50 54 27 200 227 100 100

NOTE: Totals do not include contribution of macro-operators Total operations = 3609

TABLE 7.9 Mission Spectrum

Tasks

^ y

&

II

M,

M+

M-

M*

M:

M&

x=
360 10

^^Operations I. Dead Reckoning 2. Great Circle 3. Other Tasks TOTAL/SEC 1000 1000 40 1 1000 1041 2 100 102 1 1000 1001 1 500 501 100 100 100 100 100 100 400 17 6000 6417 6000 6080 80 2 900 902 160 9 3000 3169 1500 1540 200 200 100 100 40

4000 4370

Tasks ^ y

^ ^ Operations

N$

M%

M!

M<

M>

M?

M"

1NPUTN, OUTPUTN=

(I

(I/J

REGISTERS

1. Dead Reckoning 2. Great Circle 3. Other Tasks TOTAL/SEC 3500 3500

80 10 500 590

20 I 1000 1021 1000 1000 1000

40 1 900 941 100 100

80 3 500 583

40 2 500 542 27 2000 2027 1000 1000

2 3 2 3

tooo

NOTE: Totals do not include contribution of macro-operators

107 TABLE 7.8 Macro-Operations Distribution (not to be used in determining program size)

Tasks

^ ^ ^

SIN

COS

TAN

ARCSIN

ARCCOS

ARCTAN

m*^^ Operations 1. 2. 3. Dead Reckoning Great Circle Other Tasks TOTAL 1 4 8 13 2 3 8 13 3 3 1 5 6 1 1 1 5 6

OTHERS (20)

20 20

TABLE 7.10 Macro-Operations Spectrum

Tasks ^ ^ ^ 1. 2. 3.

SIN

COS

TAN

ARCSIN

ARCCOS

ATCTAN

Operations 20 4 50 74 40 3 30 73 10 10 1 20 21 4 4 1 16 17

OTHERS (20)

Dead Reckoning Great Circle Other Tasks TOTAL

300 300

times during a statement. Every operation of the type ' , ' , 'M', 'INPUTN,' 'M' ", encountered during one statement, read from left to right, adds one register to the number of those required. All the other operations or macrooperations encountered modify the number of registers according to the following rules: (a) (b) (c) (d) + * : & ' decrement the count by one, M+ M - M* M: M" " N$ M! leave the count unaltered, X = OUTPUTN = M< M < M? reset the count to zero if encountered at the end of the statement; otherwise they leave the count unaltered, M% affect the count depending on the number of their operands and of their results. For example, trigonometric functions operate with one operand which they replace with one result, leaving the count unaltered.

It has to be remarked that the number of registers that appear to be required depends on how the statements have been written. One can find out the statements which yield the maximum count and take this latter as the number of registers needed. Such number, in any case, cannot be unreasonably high; if this were the case, the contributing statement would have to be split into more parts, each part entailing a storage of an intermediate result into memory. In this way, machine registers would be saved, at the expense of additional memory cycles. Macro-operations are listed, as said before, in separate Tables 7.8 and 7.10, with related quantities and recurrence frequencies, for each of them. Each macro is then to be analyzed in terms of elementary operations, exactly as if they were tasks of their own. The results of this analysis are shown in another section, (7.4.8). The reason for this procedure will be more clear later, when the instruction set is introduced: having the macros separated is very important to dedde whether they have to be implemented by hardware or by software. The procedure described before does not give a complete spectrum of the mission, when a significant amount of data is stored in memory in the form of fields of words. This situation produces an additional work load in terms

108

of masking and shifting, which can be estimated to be proportional to the totals of the fetch and of the storage operations performed on fields. With reference to the example 7, the following rules apply (the underlined part representing the overload (a) fetch of a field (FIELD) from a word (WRD) FIELD: entails: WRD,MASK&N$ (b) fetch, with operation, of a field from a word FIELD'op'ENTAILS: WRD,MASK&N$'op' (c) storage of a field RESULT,FIELD = entails: RESULT,N$WRD,MASK&WRD= where RESULT, as its name implies, is the result of a series of preceding operations. To render such estimate easier, it is advisable to call field operands with names which recall their nature (e.g., appending an F to their mnemonic). Other additional workload is required for scaling shifts. The extent of this depends on the task, but in most cases it can be estimated that about 20% of the arithmetic operations require scaling. Within such limits, fixed-point arithmetic is suitable. Should the scaling load become excessive, floating-point arithmetic may be advisable. 7.4.6 Memory for Data Data and instructions are to be stored in a certain number of memory words. The problem is to choose the word length in order to obtain the best compromise between memory size (cost) and workload to store and retrieve data and instructions. The following considerations are to be made. If each data occupied a single word only a memory cycle would be required to fetch it. Since data usually have very different lengths, this solution would probably waste memory. On the other hand, short word length would help to increase memory utilization but would require multiple accesses to fetch long operands. A compromise between these two extremes must be found: the proper word length should match the length of most data without excessive memory wasting. The few long data would fit in double words. Short data could be either put in single words, if very few, or grouped, two or more together, as fields of words. In the latter case, their fetch would require overwork for masking and shifting. The choice of the word length can be made easier by plotting a histogram of data lengths as shown in Figure 7.5 for a hypothetic example, which could apply to the complex tasks already described, assuming certain values for word lengths. From the figure it can be seen that if a word length, say 12 bits, were selected 600 + 800 + 550 = 1950 data would occupy a single word each, while 1600 + 3200 + 1100 = 5900 data would occupy a double word each. A total of 1950 + 5900 x 2 = 13,750 memory words would be required. Memory capacity in bits would be: 13,750 x 12 = 165,000 bits. Memory occupancy would be 99,400/165,000 = 0.6. If a 16-bit word length were chosen, the following results would be obtained: 600 + 800 + 550 + 1600 + 3200 + (1100 x 2) = 8950 16-bits words: 8950 x 16 = 143,200 bits. Memory occupancy: 99,400/143,200 = 0.69. If the three shorter groups of data were grouped in two-field words, they would be contained in 1000 words, so the total words would be 8000. Then 8000 x 16 = 128,000 bits. Memory occupancy: 99,400/128,000= 0.78.

109

In the latter case, the time for fetching would increase. The extent of the increase can be evaluated as said in a previous section. It is to be remarked that grouping should be limited to data belonging to the same table message, i.e., data used by the same programs, in order to simplify addressing. The procedure for organizing memory for data can be summarized as follows: (a) The data defined during the functional analysis are subdivided in tables according to their usage by subprograms (see, for example, Tables 7.3 to 7.4). (b) Very-short-length data belonging to the same table are joined together to form composite data (two- or three-field words). (c) A histogram of data lengths is drawn (Fig.7.5) where composite data are considered with their resulting lengths. (d) The total of memory bits for data is evaluated by adding all the lines of the histograms, each weighted by its corresponding number of bits. (e) A memory word length is tentatively selected and is plotted on the histogram. The length should be preferably chosen as a multiple of four or eight to simplify hardware. (0 The total of memory words required for data is evaluated by adding all the lines of histograms included between a single and a double word-length and so on.

(g) The number of bits of the resulting memory is evaluated multiplying the total number of words by the selected word length. (h) The degree of memory occupancy is evaluated as the ratio of the infonnation bits derived in (d) and the memory bits derived in (g). (i) The steps from (e) to (h) are repeated for a different word length in order to maximize the memory occupancy. Few tentatives are required to obtain a good result.

The memory capacity obtained in step (0 is to be increased by a certain amount (say 20 + 30%) to compensate for possible underestimates. The value thus obtained will have to be added to the words required for program storage, as later described.

s
CM

600 800 550 1600 3200 1100

x2 x5 x 10 x 13 x 14 x 21 TOTAL

= 1200 = 4000 = 5500 = 20800

44800 23100 99400 BITS

2o
Zm

O
lO

g
o o
CO

o o o

-J

16 WORD LENGTH (BITS)

24

32

Fig.7.5

Data length statistics

110

In our example, if 8000 words have been estimated (in step (0) and an allowance of 20% is applied, the total will be 9600 words. 7.4.7 Input/Output

The term Input/Output indicates the data exchange between the computer and the rest of the system. From the mission statistics the following parameters have been made available: Number of Input Channels, Number of Output Channels, Throughput for each Channel. The organization of data acquisition and distribution is described in another chapter; the problem dealt with here is the data exchange between the computer Input/Output (I/O) section considered as a whole and the computer memory. Let us recall how I/O exchanges are written in terms of elementary operations. For Input from channel N to memory location LOC we would write: INPUT N, LOC= while for Output we would write: LOC.OUTPUT N= If either operation is performed under program control, two instructions will be required corresponding to four memory cycles (t^ , as explained in the following section). If, otherwise, Direct Memory Access (DMA) is used, one memory cycle per word will be required. The latter solution is to be preferred for those channels with higher throughputs, which would otherwise consume excessive time. External program interrupts represent also a communication from the system to the computer, to ask for the modification of the program sequence in order to have some particular actions executed. Interrupts do appear in terms of elementary operations where they are treated like macro-operators; use of proper names (e.g., INT K%) may permit easy identification of interrupts. Number of interrupt channels and related recurrence frequency is thus available from mission statistics. Generally speaking, a program interrupt system can be single level or multilevel. In a single level interrupt system, as soon as an interrupt is accepted, further requests from peripheral devices are automatically locked out until a reset signal is received. The priority in executing the routines associated to different requests is stated by software under control of an Executive program. In a multilevel interrupt system, instead, the execution of an interrupt routine is stopped if a higher priority request occurs. This implies an automatic storage of the CPU configuration related to the current, lower priority routine and a reloading of the proper machine registers when the routine associated with the higher priority interrupt has been completed. The single level system is simpler from a hardware standpoint, but increases the burden of the programmer as well as the execution times. Multilevel interrupt organization is more powerful but makes use of more hardware and therefore it requires more power to operate. This latter organization is preferable when multi-programming is employed. The interrupt execution time, i.e., the time required to call the related interrupt routine to save the Program Counter and other machine registers, and to resume the preceding program at the end of the routine, restoring the contents of the above registers, depends on the solution chosen. Many possibilities exist: a few will be presented as examples with the estimated execution time, assuming that two machine registers (Program Counter and Accumulator) are saved.

Ill

(a) The interrupt channel supplies the memory address to jump to, for starting the interrupt routine: registers' saving fetch of resume instruction registers' restoring TOTAL TIME 2 tM
1 tM 2 tM

5 tM

(b) The interrupt channel defines a memory location whose contents are the address to jump to, for starting the interrupt routine:
registers' saving fetch of jump address fetch of resume instruction registers' restoring TOTAL TIME 2 tM 1 (M 1 *M 2 lM 6 tM

(c) The interrupt channel defines a memory location containing the first instruction to be executed. The instruction calls the subroutine:
fetch of call instruction registers' saving fetch of resume instruction registers' restoring TOTAL TIME : : 1 M 2 lM 1 lM 2 tM 6 tM

Method (b) and (c) are to be preferred to method (a) because they realize full program control on jump address. As far as the estimate of mission execution time is concerned, we can assume 6 t^j for every program interrupt. 7.4.8 Execution Times and Instruction Set

From the description of the tasks and from the mission statistics, a tentative definition of the instruction set may begin. It is to be pointed out that this problem does not have a unique solution, as more instruction repertoires can be conceived which comply with the mission requirements. The parameters involved are so many that, to our knowledge, no quantitative and object method has yet been devised. A solution is thus found after a cut-and-try proces which relies considerably on the skill and experience of the designer. The first quantity which is to be estimated is the mission execution time. To do this, a parametric duration is assigned to each elementary operation, as a linear combination of memory cycle t^ and of CPU cycle tcpn The operation M+, for example, is assumed to last 2t^ (one for fetching the instruction and one for executing it); the operation N$ is assumed to last t^ + Nt^pij . These assignments are based on preliminary ideas of the machine timing that the designer has already in his mind. A simplifying hypothesis which is generally reasonable is to assume tfgpu is less than tM (for core memories and parallel CPUs this is certainly true); thus during one memory cycle, more CPU cycles can be performed. An example of the process just presented is shown in Table 7.11, which applies to the example mission statistics of a previous section. It is advisable to treat macro-operators separately; in our case, each macro has been developed into elementary operations and a tentative execution time (in parametric form) assigned to it by adding those of its elementary operations. The steps of this process are not shown; approximate results appear in Table 7.12. Now, the mission execution time per second, or mission "duty", can be estimated in parametric form, by adding the frequencies F M of tM and Fppjj of tCpy which appear in the two rightmost columns of the two Tables 7.11 and 7.12.

112 The result will be an expression of the type:

D

x 4

M + F CPU

CPU < !

The value of the expression is to be significantly less than 1 (e.g., 0.5) to take into account the approximation of the method and to allow for contingencies and future expansions of the tasks. The expression contains two independent variables, but neither one is allowed to vary freely according to the designer's fancy. Hardware constraints exist, which establish upper limits that it would be impossible or simply too costly to exceed. If, using acceptable values of t ^ and t^pu , the above expression cannot be satisfied, the times assigned to some elementary operations or macros have to be shortened and the computation repeated for the new values until a satisfactory Dg is found. For example, if a macro operation orginally assumed to be implemented by software, is implemented by hardware (i.e., as a single instruction), each memory cycle t ^ required to fetch a constant or an instruction from the memory, except the first one, would be replaced by one or more CPU cycles t^py ( a s the constants would be stored in machine registers and the intermediate instruction would be replaced by sequences of machine states). The execution time would be thus considerably shorter, but at the expense of a more complicated hardware. Before we show an example computation, let us introduce another important parameter: the "response time" IR , i.e., the time elapsing between the input of a set of variables and the output of the related processing results. The value of I R is very important whenever the computer is part of a control loop. The procedure for estimating IR , i.e., the time elapsing between the input of a set of variables and the output of the related processing results. The value of I R is very important whenever the computer is part of a control loop. The procedure for estimating tR for each task is like the one just described for the execution duty Dg , but applied to the operation distribution (not spectrum) of each task. If n^M is the number of memory cycles and njcpjj the number of CPU cycles pertaining to a task, the following expression is to be satisfied.:
l

TM

*M +

TCPU

x l

CPU <

where T R is the value of the required response time, taking approximation and contingencies into account. If the expression is not satisfied, once again the operation execution times have to be adjusted. Let us now introduce an example. Let us assume a tfgpy = 0.250 //sec and t ^ = 1.0 /asec . From the totals of Tables 7.4.8.1 and 7.5.8.2, we have: FM
F

= 62,090 + 66,368 = 141,890+173,880

128,458 sec"1 = 315,770 sec - 1

CPU " DE =

whence: 128,458 x 1(T 6 + 315,770 x 0.25 x 10~ 6 = 0.207 sec/sec

which is acceptable. Once the execution time and response times have been found to be satisfactory, the further step is the definition of an instruction set. A few choices have already been made, when assigning execution times to each elementary operation: for example, that macros can be implemented by software, that multiplication and division and perhaps some macros are to be implemented by hardware. Let us now return once more to the elementary operations and to the mission statistics, and describe a number of qualitative rules to determine the instruction set. Some operations can be directly implemented by means of one instruction; for example M+ becomes: ADD contents of a memory place (specified by instruction address) to contents of a certain machine register ( a similar reasoning applies to M, M, M* M:, etc.). If more machine registers are required, it will be desirable to specify on which register an instruction is to operate: hence more ADD or SUB (subtract) or MPY (multiply), etc., will be specified. Other operations, more exactly M! M > M > M? translate directly into unconditional (for M!) and conditional jumps. Other operations, those indicated by a simple operator symbol, would correspond to "interregister" instructions. For example: * specifies that the two operands to be multiplied together are contained in machine registers. Such instructions may operate on two registers of a random-access scratch-pad, or on the two upper locations of a stack, or on two machine accumulators.

113 Frequent encounters with indicators like (I, (I/K, etc., reveal that one or more index registers will be required. As an index register is of no use unless instructions are provided for loading, storing and testing its contents, such instructions will have to be provided. Use of index registers will be normally associated with actions of this type: "Test contents of index register; if equal to N go to statement X , otherwise go to statement Y (i.e., continue a loop)", which would be written as I,N,X?Y! Such pattern of elementary operations could be implemented by means of one instruction only, of the type "Test contents of X , if equal to contents of memory location N , go to next instruction, otherwise skip it". This same reasoning can be applied to other patterns of consecutive elementary operations which are recognized to repeat themselves frequently throughout the mission description: it would be desirable to implement such patterns by means of dedicated instructions, as this would reduce mission execution duty. For example, whenever a memory location M is used as a counter of events, we will find an expression like this: M, 1 + M= which can be implemented by an instruction of the type: "increment a specified memory place by 1". Tests on status of flags are other typical cases. To end with, no instruction set would be complete without provisions for testing and for resetting Carry and Overflow and other machine status indicators. Once a tentative instruction set has been defined, provided that the number of the required instructions is not in contrast with the requirements, often conflicting, of the instruction format (see the following section), a final adjustment has to be made. Once more, no standard method exists; trial programming of some tasks or of the whole mission, aided, if the case, by simulation (see the following chapter) is perhaps the way most commonly followed to verify that the proposed set fulfills the mission requirements. TABLE 7.11 Execution Times of Operations Single Time (1) Operations ) Spectrum
T

Frequencies
F

M 1 1 1 1 1 1 1 1

CPU 1 1 1

CPU

1000 1041

1000 1041

1000 1041

+
* & a M, M+ MM* M: M& M" X= N$ M% M!

102
1001

102
1001

102
20020 18036

20(2) 36(2) 1 1 1

501 100 100 100

6417 6080

501 100 100 100

12834 12160 1804

902
3169 1540

2 2 2
2 2 20(2) 36(2)

100 100 100 6338 55440

6338 3080

200 100
4370 3500

2 2 2
1 4(4) 1 1 8(3)

400 200
8740 3500 2360 1021

28000

590
1021

1021

(Continued)

114 TABLE 7.11 (continued)

Single Time (I) Operations Spectrum
T

Frequencies
F

M 1 1 1 1 1 2

CPU 2 2 2 1 1 1

CPU

M M M? M" INPUTN, OUTPUTN= d d/J

1000 1000 941 100 583 542 2027 1000

1000 1000 941 100 583 1084

2000 2000 1882 100 583 2027

1 TOTALS

1000 62090

2000 141890

NOTES: to Table 7.11. (1) Includes the fetch of the instruction (2) In case of 16-bit words (3) Average value in case of 16-bit words (4) Includes the saving and resuming of program counter TABLE 7.12 Execution Times of Macros
Single Time Macro Frequency
T

Partial Time
F

M 32 32 32 32 32 32

CPU 120 120 120 120 120 120 500

CPU

SIN COS TAN ARCSIN ARCCOS ARCTAN OTHERS (2)

74 73 20 21 4 17 300

2368 2336 320 672 128 544 60000 66368

8880 8760 1200 2520 480 2040 150000 173880

300

TOTAL

NOTES: (1) Trigonometric functions are evaluated as 6-term series expansion, x with 16 bits. (2) The execution time is considered as an average value. 7.4.9 Instruction Word Length and Format Instructions can be classified into two main classes: (a) memory reference instructions, concernting operations on operand(s) contained in Memory besides in the machine registers;

(b) non-memory reference instructions, concerning operations on data in the machine registers. The instruction format for class (a) will consist of two basic parts: one defining the operation and the other the operand(s). The latter part could be subdivided into more sub-fields defining the procedure to find each operand

115

involved in the instruction and the location where to store the result. In the simplest case (see Figure 7.6) one operand is always stored in a machine register called accumulator, while the other is in memory. In this case, no special code to specify the accumulator is required: it is understood from the operation code. The operand part (AF) of the instruction is then completely devoted to indicate the second operand in memory.

INSTRUCTION WORD OPERATION PART OPERAND PART

O P

AF

OP
I

X AF

OPERATION CODE INDICATES INDIRECT ADDRESSING WHEN IT IS 1 INDICATES INDEXED ADDRESSING WHEN IT IS 1 OPERAND ADDRESS FIELD

Fig.7.6 Example of single-address memory-reference instruction

In more complex formats, the operand part of the instruction defines two or three memory locations where the operands are to be retrieved and the result is to be stored. In this case, the full addresses of the operands and of the result cannot be explicitly contained in the instruction: a too long word for the instruction would be required. Usual solutions to solve this problem are "indirect addressing" and "indexing". In the former solution, the instruction gives a reference to a location, either in the CPU or in a reserved part of the memory, where the full address of the operand is stored; in the latter solution, the instruction contains a partial address which is to be modified by the contents of an index register to obtain the full operand address. These two types of addressing are used also for operational purposes, to access for instance a location in a one-entry array or in a two-entry array, as will be said later. The problem of limiting the instruction word length is also presented in the simplest case of a single-address instruction, mentioned before. A solution often adopted consists of an organization of memory into pages. A page is a block of 2 n contiguous memory locations, small enough, with respect to the overall memory capacity, to be directly addressed by the n bits of the address field (AF) contained in the operand part of the instruction. An "addressing mode" code, also contained in the operand part of the instruction, indicates the way to derive the location of the page inside the full memory addressing range. Many different addressing modes have been devised. The most frequent ones are summarized in Figure 7.7, where the procedure to evaluate the operand effective address (EA, through EA5 , for the cases considered) is shown. The classification has been made on the basis of the page location, which can be either relative (to the program counter (PC) or to a point (POINTER)) or fixed (e.g., page "zero"), and of the page boundaries, which can be either variable or fixed. Variable boundaries are obtained when AF is added to the reference address, given either by the program counter (case 1) or by the pointer register (case 2). In case 1 the page is called "mobile" since it "moves" following the program counter during program execution. Fixed boundaries are obtained when the least significant bits of the address are directly derived from AF while the most significant bits (MSB) are derived either from PC (case 3) or the POINTER (case 4) or are set to a fixed number K (case 5). To choose the page size the following considerations are to be made.

116

PAGE LOCATION RELATIVE TO PC (CURRENT PAGE) (1) EAl = PC + AF (mobile page) (3) Fixed EAS = MSB.PCfAF RELATIVE TO A POINTER (ANY PAGE) (2) EA2 = POINTER + AF not applicable FIXED (e.g., PAGE "ZERO")

Variable
oo
UJ
11

cc <C

c _ _ _ _ 3

z
CO

(4) EA4 = = MSB.POINTERfAF

(5) EAS = K + AF (K=0 for page "zero")

LEGEND: EA PC AF MSB. POINTER K operand effective address program counter address field most significant bits of junction pointing register fixed number (K=0 for page "zero") Fig.7.7 Addressing modes

Data are usually organized in tables. A table is a set of data which have either the same source (input channel) or the same destination (output channel) or the same utilization, i.e., they are used by the same sub-program. To speed up the operand fetch any data inside a table should be addressed easily, once the table has been defined. For this reason, the page size should be enough to contain the longest table. If this is not practical because most of the tables can be accommodated in a reasonable page size while a few are longer, these latter could be subdivided into subtables of suitable sizes. The memory page should be chosen taking also into account the requirements for program sequencing: loops, for instance, should not be longer than a page to allow jump with direct addressing. The requirements for a certain page size are often in conflict with those of the operation code. From the programmer's point of view, having large pages means little use of indirect addressing, and therefore simpler programs which are also shorter to execute (instructions with indirect addressing require one more memory cycle than their counterparts with direct addressing). Large pages require long address fields, thus leaving few bits for the operation code and reducing the number of available operation codes for memory-reference instructions. Thus the designer is faced once more with the problem of finding an acceptable compromise between page size and operation codes, in order to optimize execution and response times. Non-memory-reference instructions, on the other hand, should not present coding problems as they would typically be specified by a dedicated OP code, leaving the other many bits of the instruction word free for the instruction code. Input/Output instructions are often in a form similar to that of memory-reference instructions, but with AF specifying the number of the input or output channel. In any case, it is desirable that the information required to define instructions be packed into a word having the same length as the data word, or in some cases a multiple of it. A mutual adjustment can be sometimes necessary to achieve a suitable compromise.

117 Indirect addressing and indexing are used also to reference subscripted locations. Two examples are considered: one-entry and two-entry arrays. More sophisticated cases can be encountered in actual programming. One-entry array Let N locations be organized into a table beginning at location TAB. Let also J be a number, ranging between 0 to N 1 , used to reference the said locations inside the table. The effective address of a generic location is given by: EA = TAB + J , where TAB is derived from AF in one of the ways said before (according to the type of page chosen) (see Figure 7.4.9.1) and J is supplied by an index register. In case of loops J can be used to control the number of iteration and, at the same time, to reference data inside the table on which the program applies. Two-entry array Let us consider a table of N x M memory locations organized as an array with N rows of M locations each. Let also J , ranging between 0 to N 1 , be a number defining a generic row of the table, and K be another number, ranging between 0 to M 1 , defining a generic location in the J1*1 row. The overall table can be considered as composed of N subtables, with M elements each, beginning at locations TABJ (J = 0, . . . , N 1 ) . The addresses TABJ can be contained in a reference table, beginning at location TAB and having N elements, addressed by J with reference to TAB . The effective address of a generic location is given by: EA = TABJ + K , where TABJ is given by: TABJ = (TAB + J) ; TAB is derived from AF as said before for the type of page used (Fig.7.6). The parentheses indicate the contents of memory location specified. J, K are given by two index registers. Using the notation described in a previous section, an operand in a one-entry array is defined as TAB(J; an operand in a two-entry array is defined as TAB(J/K (see example in Table 7.2). 7.4.10 Memory for Program The number of memory locations required to store the program instructions can be evaluated according to the following steps: (a) From Table 7.7 the total number of elementary operations in the mission is evaluated by adding all the numbers in the bottom row. In our example this total number is 3609 words. The macros are expanded in terms of elementary operations. For each macro, the number of elementary operations involved is evaluated. In our example a number of 20 elementary operations has been assumed to be required for each of the macros SIN, COS, TAR, ARCSIN, ARCOS, ARCTAN, and an average value of 100 operations for each of the OTHER 20 macros. The operations required by the macros are: 6 x 20 + 20 x 100 = 2120 op.s (d) Considering, as a first approximation, a memory location for each operation (as if a single word instruction corresponded to each elementary operation), the number of memory locations for program is obtained by adding the number of operations obtained in (a) to those in (c). In our example: 3609 + 2120 = 5729 locations. (e) An allowance is to be left for the following reasons: double-length instructions (including indirect addressing), constants, contingencies. A total of 50% can be estimated and added, yielding: 5729 x 1.5 = 8600 locations. 7.4.11 Total Memory Requirements The total requirements for the memory are derived by adding memory words for data and memory words for

(b) (c)

118 programs. The number thus obtained will represent the memory words required for the mission. In our example: Memory for data: Memory for programs: TOTAL MEMORY : 9600 words 8600 words 18200 words

The figure obtained must be rounded up to take into account the following considerations. Memories generally consist of a number of identical modules, i.e. blocks of words to which contiguous addresses are assigned. Each module is a well-defined physical entity having a number of dedicated electronic circuits and sharing other circuits with the other modules. Hardware constraints define practical module sizes, which are normally multiples of 1024 (!K) words. Typical sizes are 4K and 8K. As the total memory will have to consist of a number of modules, the memory required by the mission shall be approximated by the nearest multiple of module size which exceeds the theoretical figure. In our example, assuming 4K modules, total memory size will be 20K words. This last figure is the estimated memory requirement for the actual mission. As already said, future expansions should be foreseen. Addition and utilization of other memory modules is possible only if the full memory address has a range wide enough (the full memory address is normally not longer than a memory word). If the full memory address is b bits, the full addressing range is 2 b memory words. In our example, where 20K words are assumed to be presently required, an expansion possibility up to 32K, i.e., 60% of present memory, seems appropriate. Hence the full memory address should be 15 bits long, as 32K = 2 " . Should this be considered not enough, a maximum memory of 65K would have to be chosen, corresponding to a full address of 16 bits.

119

CHAPTER 8 MONITORING AND CONTROL OF AEROSPACE VEHICLE PROPULSION E.S.Ecdes 8.1 GENERAL INTRODUCTION This chapter discusses the application of digital computer systems to a specific problem and cross-refers to preceeding chapters. It illustrates the practical significance of individual sections and brings particular aspects into sharper focus. The discussion is concerned with a single problem the design of systems for monitoring and control of the propulsion of aerospace vehicles. The general context is related to commercial operation of vehicles using airbreathing engines. This limitation permits concentration of attention on the systems problem and removes the need for any extensive discussion of powerplant characteristics. Detailed treatments of powerplants and their operating or control characteristics are available in the literature (e.g., Reference 1). The restriction is not serious in terms of broad powerplant characteristics. The basic features of control requirements are common to all plants using chemical energy sources and combustion for energy conversion. There are strong conceptual similarities, for instance, between throttleable rocket motors and augmented (reheated) gas turbine powerplants. Time constants and thrust levels differ but the basic problems of mixture control via independent fuel and oxidant flow control and their pumping (in the general sense) remain the same. The plant control details will be less relevant to systems using hypergolic fuels and nuclear or electric propulsion. In the same way, the operational criteria will be similar for vehicles which, in themselves, are as different as the space shuttle and STOL feeder liner systems. Commercial and military operational criteria also have many analogous, if not entirely homologous, features. Similar design trade-offs are involved for both types of organizational structure and mission objectives. It is hoped that, within these limitations, the discussion will identify the basic principles involved and enable read-across to other types of operation and to other avionics systems disciplines. 8.2 STATEMENT OF THE PROBLEM The problem was given the introduction as the "design of systems for monitoring and control of the propulsion of aerospace vehicles". The solution of the problem takes place in stages (of time), through various levels of "system" hierarchy and is bounded by many interfaces between organizations. There are two major phases in the life of a system. One leads up to entry into service and includes the R and D steps, design validation and certification. The second stage embraces the service life and operation of the system. The objectives of these two stages differ and can produce conflicting requirements on the overall system which need careful resolution. The levels of the system hierarchy and their relationship with the general field of technological development are illustrated in Figure 8.1. At the highest level, technology and the sodal-economic system interact to provide an operating environment. The environment is defined primarily by legislation and controlled by regulatory bodies. This "environment" is expressed in terms of permitted noise levels, minimum safety criteria, communication spectra, traffic scheduling limitations and so on. At the next level, operators recognize new market opportunities or competitive threats from which they generate strategies leading to identification of market requirements and possibly the need for legislative modification of the operating environment. The market requirements in turn lead to definition of the primary mission to be accomplished, the facilities required to complete the mission and the support arrangements required to sustain the total activity.

120

Technology

Soc ia1-Economic System

T
Operating Environment (Legislation, Statutory Bodies)

Market Requirement

I
Support Definition Mission Definition

i
Facilities Definition

I
c
I
Airframe Flight Dynamics

1
Vehicle Specification

i
( Propulsion ) Powerplant

Systems

Communications Navigation Displays

Controls

Fig.S. 1 Overall system hierarchy

121 There are clear military parallels to this sequence leading through strategies based on response to threat or on technological innovation. The same government agencies will not be involved but the same function will be performed and the military operators will provide the same three component definition of their requirements. The operator produces a vehicle specification which fulfills his identified mission and also takes account of support and facilities available. Legislation provided the interface between the highest "system" level and the operator level; the vehicle specification is the interface between the operator and contractor levels. The "vehicle" area divides into three primary areas: the airframe/flight dynamics areas, the propulsion area and the "systems" area embracing communication, navigation and power services. The propulsion area itself divides into the powerplant per se and its monitoring and control. The propulsion control and monitoring system is usually sub-contracted by the power plant prime contractor. However, to be successful, the design of the system must take into account much more than the powerplant characteristics. It must be considered in relation to other aircraft systems such as flight dynamics, power generation and cabin pressurization. It must be influenced by operator support costs, (in repair and logistics), and by customer service (in its potential for creating departure delays). It will also be strongly affected by minimum safety levels in the choice of its failure characteristics and system reliability. The control and monitoring of the propulsion system involves direct interfaces at all levels in the system hierarchy. These interfaces frequently pose more intractable constraints on the system design than any of the technical problems involved in realizing a sound system. 8.3 THE REQUIREMENTS OF PROPULSION CONTROL AND MONITORING The simplest type of propulsion control is concerned with a single powerplant. This restricted system will be considered before discussing configurations involving several powerplants and integration of the propulsion system both with other systems and with the vehicle. The overall requirements can be conveniently dealt with in two groups: - The basic control modes for normal plant operation. - The system failure characteristics and failure responses. The Requirements of Propulsion Control and Monitoring Definition of Basic Control Modes There are four basic groups for control modes: - Start-up/shut-down modes, Steady state control modes, Transient (power modulation) control modes, Protective control modes. The start-up/shut-down modes are essentially sequencing operations which (for start-up) engage the starter, mn up pumps, apply ignition at appropriate flow and pressure conditions and schedule further combustion flows up to idling condition for the engine. At this point the engine will be self-sustaining and capable of full thrust modulation. In shut-down, the control runs down the pump flows, closes down fuel supplies and purges the lines to the combuster leaving the system inhibited. Various steady state control modes can be used. They can be based on open loop scheduling of fuel flow or on closed loop control of a specific parameter such as pressure, temperature and, for rotating machinery, shaft speed. The parameter chosen will be closely related to thrust level and may be either directly measurable or a quantity derived from one or more directly measured parameters. Different steady state modes may be engaged at different engine regimes. As an example, the idling speed of a gas turbine is a function of the density of the air entering the compressor intake. The idling fuel flow, however, is sensibly constant. It is therefore simpler to schedule an open loop control of idling fuel flow than to derive a compensated speed demand for closed loop control of idling speed. On the other hand, the ratio of absolute shaft speed to maximum shaft speed usually approximates quite closely to the ratio of actual thrust level to maximum thrust level available at a given flight condition. "Percentage" speed is therefore a useful measure of "percentage" thrust and a power level position related to engine speed is a good ergonomic arrangement.

122 An arrangement which has been used is to combine the two modes using logical switching as in Figure 8.2. The logic is organized to select the control mode resulting in the higher engine speed and the speed control loop demand is shaped to ensure that the fuel flow schedule will always be chosen at idle.

100% SCHEDULE

SPEED FLOW DECREASING AIR DENSITY, SCHEDULE

POWER LEVER SETTING Fig.8.2 Steady-state control modes

The logic operates on the algebraic value of the control error in the two modes. Mode switching occurs smoothly because it takes place when the two errors are equal in magnitude. The logic is not restricted to two inputs alone but can be used for several modes which need to be confined to the same group. The transient modes of control operate when rapid, large-scale thrust changes are called for. They prevent combustion mixture limits being exceeded during transient flow changes and the resulting flame extinction. They also prevent instability occurring either in the combustion or in the pumping systems. In this context, compressor instability in a gas-turbine is the same as pump instability in a rocket motor. The transient limits of control can be represented on a diagram such as Figure 8.3 in which compressor (pump) pressure ratio is plotted against compressor mass flow. The compressor instability and combustor extinction boundaries are shown together with a steady state operating line and constant (non-dimensional) speed lines. Increase of thrust results in a pressure ratio higher than for steady running while reduction of thrust moves the operating point towards weak extinction. The function of the transient control modes is to ensure that the locus of the instantaneous operating point lies within the two boundaries during thrust changes. The protective modes of control prevent damage to the engine which could be caused by exceeding structural design limits for temperature, pressure or rotational speed. These design limits are absolute values. A unique maximum speed boundary cannot be drawn on a "non-dimensional" diagram such as Figure 8.3 since non-dimensional speed is a function of inlet temperature. The same applies to limiting temperatures in combustor or turbine blade materials. These limits will normally be invoked during a full scale acceleration with a locus such as is shown in Figure 8.4. It is normal for five different modes to be selected during a large scale acceleration within the space of a few seconds. Mode selection must therefore be automatic and there will always be several modes available for each controlled output variable.

123

PRESS RATIO

THRUST INCREASING

INSTABILITY BO

y
EXTINCTION BOUNDARY

MASS FLOW Fig.S.3 Transient control limits

Selection of Basic Type of Control The time between mode changes can be comparable with the engine time constant itself. It follows, therefore, that real-time digital computer control has a short, environment-determined response time and must use dedicated, continuously running programs for each mode of control. The type of logical mode selection described also requires that the mode switching be effected by "polling" rather than by interrupt-type procedures. The basic program sequence for control is then: Read demand Read present parameter states Compute compensated control error values for each mode for each control output Poll error values for each group of modes associated with each control output Select one error from each group for each control output Scale and output the selected errors. (The inter-parameter cross-feeds and manipulation involved in multi-variable controllers has been omitted for simplicity.) So far, we have ignored any response-time criteria. Most of the time constants in the propulsion control system are similar or can be handled by simple forms of multi-rate sampling. All the protective loops considered have been concerned with protection against potential failure. There are some protective loops which require very rapid response to external disturbances, or to actual failures in order to prevent catastrophic secondary damage.

124

PRESS RATIO

OVER-TEMP LIMITER
'TRANSIENT* CONTROL

OVER-SPEED LIMITER

FLOW SCHEDULE

MASS FLOW Fig.S.4 Mode sequence during acceleration

There is now a choice in the structure of the system which requires a careful trade-off to be made. Is it more satisfactory to complicate the digital processing by introducing a priority interrupt stmcture and recovery procedures to respond to these conditions, or is it better to provide for them by independent-sub-systems which over-ride the primary control demands on the output actuators? There is no blanket solution to this question. There can be a real requirement for fitting independent actuators, if not complete sub-systems. The question was generated by considering abnormal operation or response to failure, particularly where rapid action was required. We are therefore introducing into the systems-choices other criteria than control of the plant under normal operating conditions. Even the most basic control requirements, such as a loop sampling rate, can be affected by considerations which have nothing to do with control theory but a great deal to do with the system as a whole. The design of the system must encompass all the possible operating conditions of the plant and controller including all their possible failure modes. Various failure responses can be required of the system. The simplest is to force a hard-over failure to a fixed limit. The result may be an uncontrolled thrust excursion in either direction but the magnitude of the excursion must not prejudice the integrity of the vehicle as a whole. This type of arrangement can sometimes be obtained by putting fixed limit stops on actuator movements, It is a method which must be used with care, however. It is appropriate to limit fuel-reducing excursions by an "idle-flow" stop. The method cannot be so easily used to restrict fuel-increasing excursions. An engine can only be accelerated by supplying it with more energy than is necessary for steady-state running. Acceleration therefore depends upon over-fuelling. Good accelerations usually require a maximum fuel flow well in excess of that needed for steady state operation at the structural limits for the engine.

125

A simple stop cannot therefore be used to limit an "upwards" hard-over excursion. Any stop would have to be modulated if a failure was known to have occurred. This defeats the whole object of a protected hard-over failure arrangement which is to make failure detection unnecessary. Where failure detection is provided, then it is as easy to arrange for soft failures to occur as to arrange for limit stop modulation. A soft failure forces the system to a defined condition. In a flight control system this condition is with the control surfaces in a neutral position. In a powerplant, the same basic "no disturbance" response is achieved by failing with the engine condition unchanged. For many failures this requirement cannot be met and a small thrust excursion will take place before the system reacts and checks further changes. The modulated throttle stop can be looked upon as an extreme version of a soft failure. However, the magnitude of the transient excursion is a fundamental system parameter with a major influence on system design. Large excursions can rarely be tolerated. The definition of a tolerable disturbance involves not only the propulsion area but the vehicle characteristics, human factors and also operating conditions. It is a "systems" parameter. It has to take into account the worst safety threat which can arise under all combinations of circumstance. Once defined, this excursion can be related back through failure detection, confirmation and reaction time to limiting actuator rate. Alternatively, where the actuator rate is fixed by other criteria, the sampling rate for the system has to be adjusted so that the failure response-time and resulting actuator excursion are compatible with the safety requirements. If it is found that the reconciliation of these requirements is difficult using a single actuator if it involves serious penalties, it becomes necessary to return to the trade-off of interrupt stmcture against separate sub-systems. The failure characteristics are now also involved. We see too, how actuator response and failure excursion interact with sampling rate and that some of the basic "control" parameter choices can be determined by overall system considerations rather than by a simple approach to control of the plant itself. 8.4 DEFINITION OF DESIRED FAILURE CHARACTERISTICS The definition of a set of failure characteristics is a full-scale systems operation. It involves all levels of the systems hierarchy. Aircraft accidents are inevitable. Commercial operators fly into many countries and few accidents are purely internal matters. The risk of an accident does not depend exclusively on the vehicle. It depends upon ground facilities as well, upon features which are determined partly by economic factors and partly by technological capability. The operating environment is therefore involved. The certificating and operating regulations vary from one country to another. Failure characteristics for a vehicle which is to be sold in several countries must take account of the most severe regulations it will have to meet. Unrestrained commercial determination of safety levels is inadmissible. Minimum standards of safety are set by certificating bodies in consultation with the operators and with the manufacturers. While commercial factors are deeply involved in setting the level, they are not the only factors considered. The levels cannot be manipulated to reduce operating costs once they are agreed. From this point on, there are three levels of working, one appropriate to each of the certificating authority, the vehicle contractor and the systems contractors). They have different responsibilities and different working methods. Conditions can occur during operation of an aircraft which involve a potential lowering of the level of safety. These occurrences may have their origin in equipment failures, in human errors or in uncontrolled events outside the vehicle. They may be encountered singly or in combination. Each occurrence will give rise to an effect which may be classified as minor, major, hazardous or catastrophic. The function of the certificating body is to define levels of probability for each of these effects, the combination of failures, errors and outside events which must be considered and the procedures to be used in demonstrating that the requirements have been met. The aircraft manufacturer's task is to define all the situations and occurrences which could cause the effects. Some occurrences, such as weather or turbulence will be uncontrolled. Some human factors will be only partly controlled. The remaining factors must be manipulated so that the permitted frequency of each effect is not exceeded. These factors will include loss or degradation of various functions in the vehicle and the manner of their loss. The permitted failure rates and failure trajectories are then incorporated in the manufacturer's equipment specification.

126 The manufacturer may use several analytical procedures in arriving at the equipment specification. One of the most satisfactory methods of formalized working is the Fault-Tree Analysis (FTA) originally developed by the Bell Telephone Company while devising systems which would prevent the accidental launching of a Minuteman missile. The results of the analysis are presented on a flow chart, usually using Boolean operator symbols. An illustrative partial FTA for a hypothetical VTOL aircraft is shown in Figure 8.5. It starts from an "effect" specification given by the certificating authority and proceeds to analyse the possible routes to this effect. The "loss of aircraft" effect can arise with the aircraft airborne through collision or sabotage (which are essentially human factors) or through stmctural failure (e.g., through fatigue or by atmospheric effects such as clear-air turbulence). Similar reasoning can be applied when the aircraft is on the ground. Surface impact can arise in several ways. Figure 8.6 expands the analysis for surface impact in the VTOL mode of flight due to causes associated with loss of control or temporary degradation of control. It indicates how the analysis can be extended into the equipment manufacturer's area. The extension is illustrated for the particular case of sudden thrust changes caused by failures in a control loop operating in a protective mode and limiting a critical temperature in an engine. The failure can be in the temperature datum. False datum selection caused by relay failure and datum offset caused by parametric drift in transistor circuits are indicated. Incorrect datum may also be selected by the crew, bringing in ergonomic factors at the crew interface. An alternative source of failure is a false, high indication of the actual engine temperature. Illustrative hardware failures are shown. The total probability ofthe "loss of aircraft" is arrived at by summing all the contributions through the tree, thereby exposing the relationships between uncontrolled events and detailed equipment failures. The procedure will often disclose implicit coupling of responses - for instance, the way in which pilot reaction can convert a sudden thrust increase into an actual thrust decrease. There are, in fact, two forms of "fault" which must be considered. One is a thorough-going failure such as those at the foot of Figure 8.6. The other is a degradation of performance an insidious failure which is difficult to detect in normal modes, defining their effects and frequencies, but also bounds the tolerances on performances in normal operation. This last feature should remove most of the "conceptual deficiency" failures shown in Figure 8.6 - as indeed is its primary purpose. The confidence in the analysis and the probability of its including a significant error must be matched to the permitted probability of the ultimate effect. This stage of the system definition is particularly complex because of the extreme rigor which is demanded and the inter-action and interchange between the aircraft and equipment manufacturers. It ends with a general specification of performance tolerances as well as the characteristics and frequency of abnormal deviations in performance. The "reliability" specification for an equipment is fully defined at the aircraft contractor/equipment supplier interface on the FTA. It appears in terms of failure modes and their maximum permitted probabilities. A rapid, preliminary estimate at this stage will usually indicate the type of failure protection required for each failure mode. Single failures with no protection against their consequences may be acceptable for modes involving very reliable equipment or minor effects. Others may need fail-safe protection (either hard or soft) while others again may involve a combination of less reliable equipment and catastrophic effects which demands failure surviving, fail-operational redundancy. In extreme cases it may be necessary to provide survival for multiple failures. The problem solving has now been shifted to a lower level of the hierarchy and is concerned with the stmcture of a particular system function. 8.5 SYSTEM SELECTION AND ARCHITECTURE Two steps have to be taken once the equipment supplier/aircraft contractor interface has been fully defined in the FTA. These steps, in order, are: (a) To define those functions which will fall within the compass of a single system or sub-system.

(b) To define the architecture of the system or sub-system so that it meets the performance and failure characteristics required of it in as near optimal a manner as possible.

EFFECT MAXIMUM PERMITTED PROBABILITY ' A " PER FLIGHT CERTIFICATING AUTHORITY AIRCRAFT CONTRACTOR

BOOLEAN "AND" FUNCTION ONLY A OCCURING WITH B RESULTS IN C

BOOLEAN "OR" FUNCTION EITHER DOR E RESULTS IN F

Fig.8.5 Illustrative fault tree analysis

128

Fig.S.6 Continuation of illustrative fault tree analysis

Selection of Functional Groups for Systems and Sub-Systems Digital computing and the general introduction of digital techniques into avionics is changing the ways in which functions are grouped. They provide ways of divorcing hardware stmcture from the problem solution which is embodied in a computer program. They provide ways of time-sharing, so that several programs can reside and run in- a single computing element. They provide ways by which data signals are readily multiplexed over a simple circuit and, furthermore, make the isolation of the various signal sources simpler. They are therefore making it easier and potentially more profitable to combine functions within a single sub-system. The combined automatic functions can be approached in two ways, bodily, as an integrated whole, or alternatively as a cohesive assembly of inter-communicating but relatively autonomous functional groups. These approaches underlie the "integrated" and the "federated" systems approach to avionics. The two approaches can produce radically different sets of functional grouping. Integrated systems generate new product specializations - for instance multiplexed data transmission or displays and controls. The arrangement where each sub-system included its own controls and displays is not appropriate to an integrated approach, they become a part of a separate sub-system which exists in its own right. Generally, systems management organizations will try to simplify the procurement interfaces. Thse interfaces are partly determined by historical influences and industry stmcture which change neither so readily nor so rapidly as the available technology.

129

A particular functional grouping may be precluded because, although the grouping is natural and conceptually satisfying, it deflects an existing management interface and is a potential cause of deficient human communication. The particular grouping of functions can also depend upon mission characteristics. The traditional division of control in an aircraft powerplant is shown in Figure 8.7. Separate controls are provided for air inlet, the flange to flange dry engine and the tail-pipe/augmentor section. Responsibility for the plant components themselves is also split in the same way, the air intake being the responsibility of the airframe manufacturer while the engine and tailpipe sections may be undertaken by different engine manufacturers - possibly in different countries.

INDEPENDENT VARIABLES _

b
I
ENGINE CONTROL.

COMMAND INPUT

AUGMENTOR SELECT

LJJ
INLET CONTROL A

Li
INLET CONTROL B

I
ENGINE CONTROL B

AUGMENTOR CONTROL

A_

SENSOR/ ACTUATOR SET

SENSOR/ ACTUATOR SET

SENSOR/ ACTUATOR SET

SENSOR/ ACTUATOR SET

SENSOR ACTUATOR SET

JL
FLIGHT CONDITIONS

T
ENGINE

T
TAIL-PIPE

INLET

AERODYNAMIC COUPLING Fig.S.7 Powerplant control system

AERO-THERMODYNAMIC COUPLING

Now the mission profile may be such that the augmentor is only called into operation at take-off and during the early climb phase. Somewhat lower levels of reliability could be tolerated for its control system than for the bare engine. Similar criteria can also apply to the inlet control if the periods of supersonic flight are short or a requirement for a sub-sonic reversionary flight mode is not economically or tactically onerous. The three functions can therefore require three different levels of redundancy in order to meet their reliability criteria. It can be argued that the powerplant is an entity and that its total control forms a natural functional group. An integrated powerplant control forms a natural functional group. An integrated powerplant control is shown in Figure 8.8. It shows a need for isolation where the data bus system connects to common equipment. It shows a need for consolidation when two possible drive signals are present. The consolidation function could be avoided by only sending one signal to the augmentor actuators. This could be arranged by having the control programmed in only one of the two control computers shown. The arrangement would lead to logistic problems if the programs were hard-wired and two different computers were used.

130 It would be difficult to offset the cost penalty by savings in hardware unless the augmentor control were extremely complex, and then the reliability of the engine control itself could be compromised. A program flag arrangement can be used to inhibit the unwanted augmentor control in one of the computers. It has to be implemented so that it is impossible to flag the program in both computers simultaneously and that there is an immediate, external and visible indication that a program has been inhibited.

INDEPENDENT VARIABLES m K

POWERPLANT CONTROL LANES LANE A LANE B

COMMAND INPUTS

I
^

ii

ISOLATION

ilit

T
1
ISOLATION

ISOLATION

DATA BUS A &B

SENSOR SET C

I
CONSOLIDATION
SENSOR/ ACTUATOR

SENSOR/ ACTUATOR SET A

en
INLET

SENSOR/ ACTUATOR SET B

SENSOR/ ACTUATOR
SET A

SET

SENSOR/ ACTUATOR SET

I
ENGINE Fig.S.8 Integrated powerplant control

I
TAIL-PIPE

Assuming that this is done, there remains the problem of allocation of responsibility if an augmentor mulfunction occurs. Did it originate in the hardware on the augmentor side of the data-bus, in a data-bus failure, in a computer hardware failure or in the augmentor control program? Integration of functions must be accompanied by precise fault isolation where the realization of a given operation cuts through several areas of responsibility. All of these implications must be included in selecting the functional groups which define a system. We have so far only considered functional grouping at the powerplant level. In normal operation, the powerplant settings are manipulated collectively, controlling the overall propulsion complex for the vehicle. Differential control of individual powerplants is generally only used during ground manoeuvres or to make small adjustments for powerplant-to-powerplant performance scatter. Automatic control of total thrust is already in use in all-weather landing systems and in some autopilot modes. Much more could be done than modulate the thmst set-point.

131 Figure 8.9 shows a system arrangement with a high level propulsion control sub-system. Full use of the capabilities of a digital computer could optimize the individual plant control inputs to obtain optimum aircraft performance at any flight condition. It could trim engine time-response to large commands and avoid yawing couples set up by different engines changing thrust level at different rates. It could monitor individual engine performance and generate displays.

CONTROL AND DISPLAY

HIGH-LEVEL PROPULSION CONTROL SUB-SYSTEM

i

r
|

i
OTHER SUB-SYSTEMS

~1
y~

I
, t
11

i
DATA y i r OUo DATA BUS 1 2

X
>.
mZ

1
i

MANUAL CONTROL INPUTS

CONSOLIDATION AND AUTO/MANUAL CHANGE-OVER

INDEPENDENT DISPLAYS

-J
a

* POWERPLANT CONTROL

* POWERPLANT CONTROL

POWERPLANT CONTROL

1
POWERPIANT

POWERPLANT

POWERPLANT

Fig.S.9

Integrated propulsion control

However, none of these functions are essential to keeping the vehicle in the air. They have economic significance but no safety of flight value. It is important that functional groupings allow for this type of division. Under many circumstances it will be of greater value to make a sub-optimal flight without the high-level sub-system than to make no flight at all. The two groups of functions could be so inextricably bound up into a single operating configuration that any failure, including one in the non-essential sub-system, would ground the aircraft. The consolidation point where the propulsion and powerplant sub-systems interface with each other must therefore also be a point at which the two sub-systems can be easily decoupled. The two systems must be segregated to prevent fault propagation between them and a reversionary interface must be provided at the same point so that manual or an alternative form of automatic control may be substituted for the propulsion control inputs. In presentday systems, all of these features are provided in a single element which drives the power levers collectively through individual clutches and a common, electrically isolated shaft. Selection of the functional groups therefore depends upon a complex set of systems influences involving the plant structure, the technology to be used, systems management considerations and operational factors. However, once it has been achieved, the selected sub-set of FTA specifications define the system failure response characteristics and allow the architecture of the system to be defined.

132 8.6 SYSTEM ARCHITECTURE The stmcture of the particular system selection will almost invariably require the use of redundant elements in one form or another. Even the simple hard-over limit stop can be considered as an extreme form of redundancy. The next level of sophistication does not attempt to survive a failure but forces the system to respond in a pre-defined way such as the soft failure response mentioned in the preceding section. This operation implies a "monitor" function, to detect failure, and an "executive" function to force the correct response. These two functions may be achieved satisfactorily by crew members manually. More often, the system will respond to failure in a violent way and the operating trajectory will be carried beyond the permitted limits. The excursion of the trajectory which must be considered passes through all the operating points between two stable states. These states are first with the vehicle operating normally prior to failure and secondly when the vehicle has attained a new steady state following failure recovery. The trajectory analysis must include not only the segment leading up to failure reaction and the resulting output excursion but also upon the trajectory followed during recovery. It does not follow that a safe terminal state at the instant of failure will also be a state from which a safe recovery can subsequently be effected. The variability, or the slowness of human response are frequently the deciding factors in determining the use of automatic reversion although examples of inability to realize acceptable intermediary states are not unknown. The same considerations appear in digital systems where the monitor is time-shared. The period between checks must be short enough to enable output excursions to be contained. Ideally, all the failure modes of the monitor and executive should be fail-safe and trigger the same effect as a failure in the monitored system itself. This cannot always be ensured but the probability of residual failures is generally low. The worst type of monitor failure is one which evokes no response and is undetected. There will be a definable probability of such a latent failure occurring which depends upon the time at risk. Even highly improbable latent failures will occur within a sufficiently long time-span. This type of latent failure is protected by periodic checks on the monitor/executive functions so that the timespan is reduced and the probability of latent failure is made acceptably small. Similar periodic checks are also required on the normal performance parameters in order to verify that the assumptions on performance tolerances used in the FTA are not violated. Significantly, and for the same basic reason, the aircrew performance is also checked at regular intervals. Provision for easy checking and the determination of safe check periods are important features of system design. Failure surviving systems need the monitor and executive functions of a fail-soft system plus a capability of reconfiguration. The new configuration may be a degraded version of the original system or may be of identical performance. Reversion to degraded operation can be achieved by a crew member switching to a simpler stand-by control. The reconfiguration is manual and the redundancy dissimilar. It is sometimes possible to reconfigure by switching out a part of the functional repertoire of control and retaining the rest of the system in full operation. The procedure is almost invariably automatic and the executive function has to be enlarged to permit control of reconfiguration. It is also important to consider the control of trajectory during the whole of either reversionary sequence to ensure that the degradation occurs "gracefully". Undegraded failure survival is also known as a fail-operational response. Its use implies that the total system includes at least two identical channels or control lanes. The lanes may be connected to the plant in either of two ways, sometimes called active redundancy and passive redundancy. In an active redundant configuration the identical lanes are connected simultaneously to the plant; in passive redundancy they are connected singly, unused lane(s) running as standbys. The two forms of redundancy share many similarities but also possess significant differences. Both configurations involve switching operations during reversion. In active redundancy a failed lane is switched out; in passive redundancy a "good" lane must also be switched in. The one can usually be achieved more reliably than the other. Switching-in for instance can involve two or three operations which must be performed, not only correctly, but in correct sequence. Switching out might be effected by the correct performance of any one of them, regardless of sequence. Both configurations require monitors. Active redundancy can be monitored very reliably by comparing lane outputs. However, if both lanes exhibit the same abnormal deviation at the same time, the failure will not be detected. Such a common-mode failure is unlikely to arise from simultaneous and identical random failures in

133

each lane. Its source usually lies in some disturbance which effects each in the same way, interference for example, or to some common design deficiency shared by both lanes. Software failures in digital systems can be a potent source of common-mode failures if the same program paths are in use in each lane. Similar common-mode phenomena exist in passive redundant systems - but with different effects. The problem here is not the non-detection of a genuine failure but the false detection of a non-existent failure. If this occurs through a software fault common to both lanes, and if the conditions provoking the failure are present throughout reversion, then the standby lane will disengage in the same way and for the same reason as the first. Whereas active redundant systems are usually monitored by cross-comparing nominally identical lanes, passive monitoring must be done by reference to an absolute standard or to a process model. It is therefore necessary to know the absolute limits within which a correctly operating system will lie. If the limits are set too wide, then some failures will not be detected; if the limits are set too close, false failure detection will lead to nuisance disconnects. Under the right conditions the nuisance disconnect will recur in the reversionary lane(s) and the whole system will shut down. A similar threshold limit occurs in cross-comparison of active lanes. The lanes are never identical, particularly in their dynamic response. The threshold has to be made narrow enough to prevent the permitted output excursion being exceeded when a failure occurs. It may then be narrower than the worst case dynamic tracking error between the compared lanes. Nuisance disconnects will now occur but without causing the whole system to shut down. Their frequency is amenable to a degree of control through design standards and manufacturing controls. Nuisance disconnect rate for passive systems can only be controlled through improved definition of the absolute behavior of system and plant, taking account of operating point and external point and external environment statistics. The discussion so far has not been concerned with the number of failures which a system may be required to withstand. Any of the procedures may be used for a first failure. The system will then be reconfigured. Its new configuration determines its response to a second failure when it may be closed down or subjected to further reconfiguration and so on. Rather than start from the initial configuration, the system structure must be built up from the terminal condition permitted by the FTA. This may define a redundant system in itself. It may further be found that it is necessary to survive more than one failure. Fail-operational lanes must then be added until the specified probability of encountering the terminal condition is met. At each configurational escalation it is necessary to reconsider the terminal probabilities. The probability of terminal failure will have been changed and monitor requirements may be modified. It is often found that the significant failure sites cluster in one area of the system and that, elsewhere, the monitoring can be relaxed. The system will possess a range of different failure effects as well as different failure sites producing the same effect. Different methods of protection may be applicable to some, but not others. It may be sufficient to allow degradation in some modes while others must retain full operational capability following a first failure. There are many possible combinatorial configurations ofthe individual structures as indicated in Figure 8.10. The selection of the set which best meet a given requirement is complex. It must take into account: Human performance - Plant performance Vehicle characteristics Equipment installation and accessibility Monitor check frequencies (including digital sampling) Control performance tolerances Reconfiguration procedures Software stmcture Sensor/actuator performance Environmental effects Detection thresholds Manufacturing and design standards. The range of choice is often restricted by some overriding requirement. It will not remove the need to consider the impact of each of these factors on the final design of a system.

1 3 4

4 Active lanes

3 Active lanes 1 model

1 Active lane + model 2 StaAdbys

AUTOMATIC RECONFIGURATION

3 Active lanes

2 Active lanes
+ model

1 A c ;t i:v e l a n e + model 1 Standby

AUTOMATIC RECONFIGURATION

2 Active lanes

1 Active l a n e + model

AUTOMATIC DETECTION

MANUAL DETECTION

AUTOMATIC REVERSION

MANUAL REVERSION

NO REVERSION

Graceful Degradation

1 Active lane (Manual R e c o v e r y )

Dissimilar Primitive System

limit stop

Uncontained

_L
SOFT FAILURE HARD FAILURE I

SYSTEM
Fig.S. 10

DISENGAGED

Reconfigurations through successive failures for redundant system architectures

135 8.7 MONITORING IN DIGITAL COMPUTER SYSTEMS The need for a monitor and executive function in almost all systems structures was explained in the previous section. It has also been shown that program repetition rate may be critical where monitoring functions are timeshared with other computer tasks. There are some other general aspects of monitoring digital computer systems which we will consider in this section. A correctly functioning computer can be used to monitor a system. Such a monitor can be both comprehensive and complex but its validity is restricted to the situation where the computer functions correctly. An incorrectly functioning computer cannot be used to monitor any system component, least of all itself. The key issue in a digital system is therefore detecting computer malfunction. Fault tolerance is not sufficient in itself. Latent failures must be exposed for rectification. There are two possible types of malfunction to consider, software failures and hardware failures. There are also two fundamental monitoring methods, direct comparison and indirect checks. Each has its advantages and drawbacks. The indirect method allows a single computer to operate in isolation. It implies that every possible fault must be considered, its effects analyzed and some means devised to detect these effects. Alternatively, and more realistically, the possible effects can be identified regardless of cause. This approach divorces the problems of detecting the presence of a fault and identifying its site. In attempting to group effects, they can first be divided into those which produce an effect at the system outputs and those which do not, i.e., are latent. Two forms of latent fault occur. In the first form, the fault lies in an unused mode or program segment but its presence will be manifested at the output when the particular mode or segment is called into use. Mission analyses will determine the potential periods of latency in different modes and periodic checks have to be introduced if the resulting failure probabilities are greater than the permitted levels. The effects are not usually troublesome because they appear as a variability in the probability of loss of the computer on any one flight. Double, independent failures are highly improbable. They can only be significant if they occur in areas having the same period of latency and called into use simultaneously. The second form of latent failure occurs in either the monitor or executive function in such a way as to prevent correct response in the presence of a second fault. All of these failures must be exposed by periodic checks. The ability to carry out such checks is an important feature of the detailed design of the monitoring and executive functions. The outputs of an on-line digital system are up-dated at regular intervals. They can therefore be described completely by the time at which the up-date occurs and by the magnitude of the up-date. A large class of failures will dislocate the program timing causing the time at which the output occurs to be shifted. The remaining failures will occur at the right time but be of incorrect magnitude. Failures causing timing errors (dislocation failures) are usually detected by an external timer. This timer will check that the computer executes a known program in the correct time and that it responds correctly to the next real-time interrupt which synchronizes the control sampling rate. The arrangement fails safe. A failure is declared if either the timer or the computer malfunctions. Errors in magnitude can arise in one of several general ways: - Errors in control (wrong mode selected) - Errors in arithmetic - Errors in memory (corruption of data). The first two sources of error are usually sought by using a self-check program which runs the computer through a short sequence of instructions exercising both control and arithmetic to arrive at a predefined arithmetic output. The output is validated by independent external hardware. The self-check has two deficiencies. It is time-shared and cannot detect failures which arise outside the time when it is running. It uses a very restricted section of program memory although it can be arranged to exercise the data store. The program memory contains important control constants which must be checked explicitly. It is therefore necessary to add an external check-sum arrangement which validates key store areas continuously. The arrangement described conducts a failure test on each and every program iteration. Two further refinements are necessary. Single, isolated output errors are unlikely to produce significant effects after filtering by the plant

136 transfer function. Error carry-over through multiple-order holds in the control transfer function also decays rapidly in most systems. It is therefore necessary to distinguish between this type of fault and one which persists. A simple "fault-duration" discriminant is not sufficient to detect intermittent faults. The executive response is normally inhibited unless the number of failures declared in any given time period exceeds a threshold value. These procedures do not provide a 100% check of the computer. They will not detect context-dependent faults nor will they detect control or arithmetic faults which occur regularly at times outside the run period of the self-check program. Some power supply faults could give rise to this type of failure if sampling rate and supply frequency are harmonically or almost harmonically related. The frequency of these residual failures has to be estimated and accepted or the use of this type of monitoring relegated to a level of the reversionary hierarchy where it does not introduce an unacceptable risk. Direct comparison methods can be used in active redundant systems. The outputs from two nominally identical control lanes are compared and discrepancies outside a threshold used to declare the existence of a failure. The method detects either timing or magnitude differences in the lane outputs and usually the threshold is wide enough to prevent a failure declaration for a single isolated fault. Where the output is not a simple zero order hold, intermittent fault discrimination can usually be arranged as well. The primary failure detection is non-specific since it does not identify the failure site directly. This is the function of the executive. It also suffers from the weakness, mentioned earlier, that software failures may be undetectable unless suitable precautions are taken. This involves comparing results obtained using different program structures and different store allocations - a feature which also reduces the incidence of common-mode context dependent failures. Difference of program stmcture introduces potential problems of the type covered earlier when discussing integration of augmentor and engine control. An important feature of system monitoring is that it should not confuse equipment failures and plant failures. If the plant fails it is usually important that the controller continues to function rationally. It is worth noting in this context that active redundancy sees plant abberations as a common mode disturbance leaving an output comparison monitor unaffected. The same type of behavior is much more difficult to achieve when an indirect monitor is used. The primary function of the executive is to define the site of the failure, at least to its location within one or other of the active control lanes. The problem of fault isolation within the confines of one lane are similar in both monitoring configurations but potentially more positive in active redundancy because (for single failures) the indications of a greater part of the overall system can be available and relied upon. Identification of a failed lane can be positive where there are three or more active lanes and multiple faults are excluded. Various algorithms may be used of which the most common are: (a) Majority vote - disengage the lane with the greatest divergence from the system average. Revert to two active lanes. (b) Median select - retain the lane with the output closest to the system average. Revert to a single active lane. Even when only two active lanes are connected, it is possible to devise algorithms which determine the most probable lane to have failed. A reversion to that lane can then be made provided that an incorrect reversionary selection permits manual recovery within the permitted output trajectory under failure conditions. Complex logical algorithms may be required to determine the selected lane. In some system modes simple "select highest" or "select lowest" algorithm can be used. The executives used with both types of monitor must effect the necessary lane disengagement/engagement procedures and generate any status or warning displays. In both types of system the executive hardware will be independent of the computer and may be redundant. 8.8 DATA ACQUISITION. COMMUNICATION AND PROCESSING Up to this point we have only been concerned with features of power systems involved in control or in failure protection. The vehicle is a component of a much larger operating system which places other demands on the propulsion system equipment than on-line control. It is necessary to monitor plant operation for other reasons than protection against sudden catastrophic failure. It will always be necessary to overhaul the powerplants from time to time and the procedure is expensive.

137

For many years, powerplants were removed for overhaul at regular intervals. The period between overhaul was set to keep the probability of critical failure at a sufficiently low level. It was short when a new powerplant entered service and gradually increased as background experience was accumulated. Early failures occurred and their causes were removed by development. Some of the failures occurring between overhauls were not associated with any predictable cause or with causes which were subject to wide variability. The relative frequency of these incidents increased as the overhaul life increased. Overhaul lives for mature engines are not extremely long and there is a need to monitor the engine behavior in order to predict premature failures before they occur. The interest is not only greater safety, the maintenance costs of a large fleet can be appreciably reduced if an aircraft can be scheduled through a maintenance base and an engine change before a failure actually occurs. By definition, the type of failure involved is one which gives early warning well outside the duration of one flight. Two other failure time-scales are recognized in the stmcture of the total monitoring operation. Some failures will occur relatively slowly but the time between detecting the threat and experiencing the event is less than a typical flight time. Others occur so rapidly that an immediate corrective response is demanded. The response must be automatic if it lies within the combined attention-span/reaction-time limits of the crew. The control must respond correctly to this type of failure as mentioned in an earlier section. The slower type of failure can be handled manually and there are good reasons for leaving the crew to make the decision to shut-down a powerplant. Monitoring for this class of failure therefore requires a display of critical data to enable the progression of the failure to be observed. The requirement is not that the condition should be recognized via the display although this is effectively the procedure when individual instmments are used. Much more sophisticated systems are possible using digital analysis and processing of measured data to detect incipient failure, and with flexible CRT displays to alert the crew and provide selective displays of powerplant status. The displays can be reconfigurable, either on demand, or under program control. They are both discriminatory in selecting the data and, through processing the memory, able to present more meaningful displays than instmments reading engine quantities directly. All of the monitoring/display operations must be conducted in real time but the sampling rates and solution rates can be much slower than those for control. The computation can be either inter-leaved or run in a background mode. Many of the control system inputs may be shared and be common to the monitoring system. However, there may be a requirement for duplication of the sensors and of the display. The need arises when the plant spends long periods at a fixed power setting. If the controller fails in a fail-soft mode early in the segment it is often desirable to keep the plant operating until a change of condition is required. The fixed setting can be retained even longer if sufficient thmst change can be obtained by over-modulating remaining powerplants. Abandoning a supersonic cruise segment is obviously undesirable. It can be avoided with a fail soft system provided that sufficient independent displays are present to allow the crew to monitor a control-less powerplant adequately. The monitor functions for the very short term failure and for the failure appearing within one flight time must be real-time on-board systems entirely. The long-term failures require both an on-board feature and a link with a much larger fleetwide data processing operation. The on-board feature provides a quick-look between flights. It is particularly useful with damage accumulation failure mechanisms where the rate of accumulation can vary widely from flight to flight. A purely on-board system of this type has one grave disadvantage. The data on which the presentation is based is destroyed and only the result preserved. A further problem arises when an engine is changed at overhaul. Damage accumulation failure modes usually relate to a given component in an engine. At overhaul, an engine is stripped and rebuilt. The rebuilt engine can have a different mix of components each with a different accumulated damage figure. It is therefore necessary to track component histories through a fleet rather than the history of a given aircraft. As an added complication, different versions of the same basic component may have different damage and accumulation rates, as a result of design modification or material changes. The on-board system is an aircraft item. It would therefore have to be subjected to frequent up-dating to take account of all of these variations at each engine change. Any interference with store contents is a potential cause of degraded integrity. The data store would have to be non-volatile and electrically readable but non-alterable by the propulsion system alone. Additionally, the reliability of the propulsion system would not have to be degraded very significantly by whatever arrangement was used. For all of these reasons, the on-board elements must be kept simple. The major data processing functions are conducted off-line and preferably at a fixed location. The essential features are therefore an on-board arrangement for recording data which can be quickly recovered after a flight, a data transmission network between operating stations and the main data-processing centre and a large D.P. installation.

138 The precise form of the on-board configuration depends upon the data processing on the ground and particularly upon the communications network. The system configuration for a large-wide airline operation is not necessarily the same as that for a more localized operator. The first might require data compression prior to transmission in order to keep operating costs and queueing delays within reasonable limits. There are therefore several identifiable levels of monitoring operation: Data logging for batch input to a major data processor on the ground, Quick-look status checks for use during vehicle turn-around, Flexible generation and presentation of selected powerplant status during plant operation, Detection of slow approaches to failure and generation of crew alert, Detection of imminent failure and generation of immediate automatic response, Provision of monitoring continuity after a control failure which leaves the plant operating normally. All of these, except the last, form an integral part of an automatic propulsion control and monitoring system. They will require the use of input scanners with program controlled frame format, foreground/background computational operation, generation of data for a display sub-system and the preliminary processing and formatting of data for compatibility with D.P. recording and line communication standards. 8.9 MAN-MACHINE INTERFACE The man-machine interface in a propulsion system must, of necessity, be as simple as possible. Innovations must be introduced slowly and with caution. The deceptively primitive interface of the traditional "power lever and instmment" interface embraces subtleties of which we are only partially or vaguely aware. The power lever (and the more recently introduced thrust vector lever) is the primary control channel between the crew and the propulsion machinery. The lever position cannot be calibrated in a universally meaningful way. Furthermore, it is designed to be easily pushed - and "ready to hand" ergonomics conflict with any "easy to read" location. Conventionally, some measure of power setting is displayed on an instmment and the reading adjusted by moving the lever until the required setting is obtained. The power setting required is often set up on a "bug" on the same instmment so that actual reading of the instrument is not required. It is sufficient to align the bug and the indicator. Different measures of power may be used in different flight regimes and in different aircraft. The measure may be a direct engine parameter such as compressor speed, a gas temperature or an engine pressure ratio. Under other circumstances the measure may be indirect and displayed on another instmment (such as airspeed or rate of descent) but the same principle is used. The basic requirements are therefore for the generation of an appropriate setting, a measure of the actual setting and a manual input channel through which the actual power level may be modulated. At different points in the mission the powers may be required to be vectored in some way (e.g., thrust reverse during a landing roll). At others, the augmentor must be engaged and controlled. Frequently, the propulsion system will be controlled automatically. Interchange between automatic and manual operation must be provided simply and smoothly. All of these requirements are met through a single lever. Thmst reverse is engaged by pulling a toggle which is only operable at "idle" settings. The lever then controls the level of reverse thrust. Augmentor control is operated by advancing the lever through a gate. The lever is included in the automatic control loop which drives the lever mechanically. Its physical position always corresponds to the reigning engine condition. For multiple powerplants the levers are grouped and can be operated collectively by the palm of the hand or staggered to give assymetric thmst. This simple arrangement is unlikely to be changed. The generation of the setting and the indication may change. The present collection of engine instmments is cumbersome, heavy and wasteful of panel space. It could be replaced in a smaller space by a CRT display on which the data is selected according to need and is probably more directly related to the power requirement. The introduction of such a display introduces two changes. The first is one of display format. Conventional displays are needle and scale, plus digital readout for some parameters. The display, although used primarily for

139 power control, is used in a secondary role as a monitor. Angular divergence between needles appears to be more readily assimilated than bar or thermometer displays. This and other ways in which perceptual correlations are involved require careful exploration in establishing any change of format. The individuality of existing displays has advantages. There are many fewer types of indicator than there are indicators on the panel. Each one is relatively cheap. Spares can be distributed without too great a logistic investment problem because an adequate spares kit usually costs much less than the full instrument complement. This is changed drastically when all the displays appear on a single instrument. Logistic costs will increase unless the single instmment price is as low as the original spares set. Again, with the independent indicator arrangement, there is a fair degree of redundancy in the displayed data. An aircraft can be despatched with certain instruments non-operational. It is unlikely that a CRT display would be regarded as an allowable deficiency even though the displays would certainly be duplicated. Every display failure therefore becomes a delay and spares must be rapidly available at all stops. The man-machine interface is subject to the same system constraints as all the other aircraft equipment, the same trade-offs of performance versus economics. Digital methods could be used with advantage to generate the power demands or power limits and various proposals for push-button or "dial-up" arrangements have been made. None of these has yet been used. 8.10 PRACTICAL REALIZATION Up to this point we have been concerned with the definition of requirements of one sort or another. We have considered the type of control and monitoring functions which may be required for propulsion. We have considered the definition of functional groupings which will be involved. We have considered the process by which safety of flight affects performance, system architecture and some of the fundamental control parameters and we have looked at some of the ways in which the system might be structured. A preliminary set of requirements for a particular system will include a specification of: Functions to be provided (with defined performance characteristics), - Plant data, - Failure characteristics (effects and frequency of effects), Interface definitions (mechanical, electrical, environmental, data, procedural). It is unusual for the plaat and its control to be designed and made by the same organization, yet they operate as a whole. There are two approaches which can be used in the control specification. In the first, the control performance is specified independently of the plant. In the second, the performance of the controlled plant is defined, together with the nominal plant characteristics. The control designer is left free to select his control strategies within this framework. The most significant difference between the two is probably that the first involves a much narrower dissemination of plant performance data. The preliminary specification will be refined by exploratory trade-offs. A given function can usually be realized using different combinations of measured parameters. The cost, size, weight, accuracy, response and technological risks of the alternative approaches must be assessed and a particular solution chosen. This process builds up a detailed definition of sensor interfaces and the parametric relationships involved in the control laws. Similar trade-offs are required in the system stmcture to define the best arrangement to meet the safety requirements. These must also take account of interactions with performance requirements through the actuators and plant characteristics. The trade-offs will involve the definition of computing and data characteristics for the alternative architecture, the study of failure monitor and executive hardware, the selection of candidate computers and input/output structures, the assessment of mn time, store size and system reliabilities. Selected versions will then be compared on estimated size, weight, cost, timescale and risk. The weighting of each factor will depend on the particular goal of the overall vehicle or powerplant design. At this stage the system outline is approaching final definition and the residual trade-offs become more detailed within it. The preliminary trade-offs will have used simulation procedures. Certainly, the plant and controller will have been simulated to verify control law assumptions. Indeed, a simulation is often the only way of arriving at plant characteristics at this stage of the work. A controller is required very early in the powerplant development program, if not for the first runs of a new engine. Engine development starts by rig testing of individual components - compressors, burners, turbines, etc.

140 Although initial simulation may be purely theoretical, improved data allows it to be improved as component test data becomes available. However, rig data is not always representative of the component performance in an engine and the simulations used may be in error until full scale engine mns have taken place. This applies to both dynamic and steady-state characteristics. Simulation of the controller itself may be general, in the sense that no attempt is made initially to represent the characteristics of any particular control computer. Later trade-offs may require the use of an emulator to identify realistic mn-time and store size values for particular machines. Two types of simulation are used. The first type does not run in real-time. The plant characteristics are simulated accurately but time constants are scaled arbitrarily. This permits investigation of sample rates and the use of emulations with no restrictions on the computer in which the work is actually conducted. System hardware may be included in a simulation, for instance to permit proper representation of nonlinearities, in mechanical components. The simulation must then mn in real time and a simpler, less accurate simulation is used. Very often the investigations are concerned with restricted ranges of engine operation and simple transfer function simulations can be used. These simulation procedures are used extensively and throughout the system development. Where the specification is written in terms of the combined controller/plant performance a reference simulation may be used in quality assurance testing of the system performance prior ro release for delivery. Proper use of emulation techniques allows the development of the hardware to proceed independently of program development. Many of the essential software characteristics can be defined and program debugged in some detail before a real-time evaluation is possible. Long development times are characteristic of aircraft powerplants. The lead-time from first run to entry into service is normally much longer than the time between first flight for the aircraft and entry into service. This reflects the greater uncertainty in the performance of the powerplant at the time it makes its first mn. It arises, partly because of the component characteristic uncertainties mentioned earlier and partly because the complexity of the aero-thermodynamics is much greater than for an aircraft. An engine is usually subjected to considerable development modification prior to entry into service. It is often changed after entry into service to realize performance stretch as well as to cure in-service problems. These changes must be accepted and the system designed to take account of them. Major changes in hardware are very unlikely to occur, or can be buffered, but the program will be subjected to frequent changes in service. These features have considerable influence on software and on the choice of memory stmcture. Software Considerations The primary demands on software are: (a) It should be efficient. The requirement for development change implies a reprogrammable store. Cost, size, reliability and environmental tolerance can all demand a read-only, minimum-size store for service use. Program translation between the development and production phase is an added cost since a thorough validation process is required on the translated version.

(b) It should be reliable. The reliability of the program must obviously be of comparable level to that of the hardware itself in order to achieve proper levels of safety. (c) It should be flexible in permitting different problem solutions to be freely set up.

(d) It should be portable so that fixed, proven solutions from one system may be carried over into another at minimum cost and risk. (e) (0 It should be easy to modify and maintain programs. It should be easy for engineering specialists to use. A systems team involves many disciplines. Programming skill must not be a barrier in access to the computer.

This set of features has conflicting requirements. The need for efficiency drives towards machine code programming which will certainly not be easy for control specialists to use. The need for reliability conflicts with frequency modification. Any software approach must therefore be a compromise.

141

The best compromise for a system using a nominally fixed program appears to be an assembler and defined set of macro/sub-routine functions operating as shown in Figure 8.11. A general set of functions comprised of lists of individual coded macros has several advantages. It is efficient and generates predictable machine code. It reduces the amount of store actually involved in program changes. It is simpler to understand and document. The machine code sections are relatively small, easier to debug thoroughly and less likely to have hidden restrictions - thus helping reliability. In addition, the macro set is extendable, new macros can be added if needed, or when available, and machine code sections can be readily inserted into a program if desired.

Assembler (any convenient language)

source program for Target Computer macro code equivalents ^ _ _ _ coding structure binary record and listing structure control statement G.P. COMPUTER Listing for Target Computer
~^m*

Object Code for Target Computer

Fig.8.11

Assembler operation

The same macro is used when a manufacturer uses his same computer in different systems applications. Often, some of the applications program segments may also be transferred. There is therefore a good measure of portability between applications. In addition, programs become portable between computers at the price of defining an assembler language input coding scheme and recording the macro set or desired sub-set. High portability is a very valuable feature of any software system because established problem solutions usually outlive particular generations of hardware. With proper choice of macro/sub-routine sets, the program writing can be made simple and readily learnt. Programs in some assembler languages are claimed to be readily generated from a conventional control schematic and almost as easily transposed in the opposite direction. It is not recommended that this method is suitable for all applications. For the particular problem of dedicated operation it has certain advantages. There is, however, a general feature which it is desirable to incorporate, where possible, into any development system. We assume that there will be a change of store technology between reprogrammable development hardware and service equipment. The development phase is relied upon to expose potential problems in service. An established sub-routine package, parts of the operating system and service routines or possibly diagnostic programs can be stored in a read-only section from the outset. This arrangement gives an economical way of gaining hardware experience. At the same time, it reduces the size of reprogrammable store required. Four types of store will probably be required in a service system. These are: Data store (volatile) Program store (ROM) BITE store (non-volatile RAM) "Modifiable Constants" store (alterable ROM)

The BITE store holds data to be used in post-failure fault diagnosis.

142 The "modifiable constants" store serves two purposes. Some of the control characteristic constants may need to be changed as engines are up-rated or even to match individual powerplants. The same store, possibly combined with designated areas of the ROM store, can be used for minor in-service changes in the program itself. The particular technology used to provide these store capabilities will change with time and will be the subject of trade-off at the hardware design phase. The essential requirements will be common to most dedicated on-line systems. 8.11 CONCLUSION This chapter has reviewed some of the system procedures, requirements and design features of the control and monitoring of the propulsion system in aerospace vehicles. It has been biased, in the examples given, towards aircraft powerplants and towards commercial operations. The principles and procedures will not differ significantly in other types of application. Even the control laws could show a strong family resemblance. The material presented has followed the sequence of the proceeding chapters and attempted to illustrate in practical terms, some of the points raised in those chapters. To this purpose it has looked beyond the present state of the art and described possible future extensions. Much has been, and is continuing to be done in this general field. Systems of this type are now flying. However, future extensions will be helped by simplifications in two specific areas. These are standardization of digital interfaces and standardization, or at least restriction, of programming languages. The task of standardization will not be easy. However, the benefits to the user are clear and there is ample historical evidence of the value of standardization to industry as a whole. Acknowledgements The author wishes to thank his colleages for help and constructive criticism and also the Institution of Electrical Engineers for permission to use Figures 8.5 and 8.6 from this paper given at an I.E.E. Colloquium on "Living with Unreliability in Computer Based Control Systems", Colloquium Digest 1972/74 I.E.E. London. References and Further Reading 1. Sobey, Albert J. Suggs, A.M. 2. Young, P.H. 3. Shutler, A.G. Eccles, E.S. 4. Grose, V.L. Control of Aircraft and Missile Power Plants, Wiley, 1963. Propulsion Controls in the Concorde, i. R. Ae. S.September, 1966. Digital Computer Control of Gas Turbine Engines. ASME Paper 70-GT^0, May 1970. Status of Failure (Hazard) Mode and Effect Analysis, Fault Tree Analysis and Prediction, Apportionment and Assessment. Annals of Reliability and Maintainability 1971 Vol.10, pp.415-422, ASME New York NY, 1971. Evaluation of Mission Severity in Cumulative Damage. Annals of Reliability and Maintainability 1971, Vol.1, pp.104-113, ASME New York NY, 1971. Condition Monitoring. ASME Paper 69-GT-66 March, 1969. Monitoring Data from Jet Engines. 10th AGARD Avionics Panel Symposium, Paris 1965. New Philosophies in Automatic Power Unit Control. BALPA Symposium, London, November, 1968. A Non-Linear Digital Simulation Method Applied to Gas Turbine Dynamics. 4th IFAC Congress, Warsaw, 1969. Pilots Response to Stability Augmentation System Failures and Implications for Design. AIAA Paper 68-819 AIAA Guidance, Control and Flight Dynamics Conference, Pasadena, California, 1968.

5. Salt, T.L. 6. Kockanski, K.B. 7. Taylor, H.N. 8. Eccles, E.S. 9. Dennison, C. 10. Johnson, W.A. Weir, D.H.

143

CHAPTER 9 MAN-MACHINE INTERFACE E.Keonjian 9.1 INTRODUCTION As the complexity of aerospace systems grows, the requirement for augmenting, expanding and simplifying crew control capabilities becomes more demanding. Thus the man-machine interface, which essentially is a problem of exchanging data between the system and the human has become more crucial for the operation of modem aerospace systems. To cope with this problem a new class of information - processing systems (aerospace computers, multiprocessors, multiplexers), control systems and displays have been developed, and the trend toward greater integration is realized. As a consequence, the degree of pilot/operator involvement with the machine has increased in scope and complexity. This chapter reviews briefly some basic elements of the man-machine interface optimization process and its relations to the total avionics system design. 9.2 HUMAN CAPABILITIES AND LIMITATIONS OF THE CREW The emphasis on automatic controls in modern aerospace systems has considerably altered the role of the human operator in such systems. His task lies more in monitoring and decision making areas than in control. Hence a systematic methodology is needed to test the adequacy of the human operator to perform the tasks, procedures and required decisions, optimized with respect to the functional requirements imposed upon the man. This requires a quantitative understanding of human capabilities in complex decision and control tasks. Considerable data are available on the information gathering and processing aspects of human behavior1 which illuminates the necessity to dwell on this subject in this brief chapter. From these results mathematical models of human decision processes and adaptive behavior have been proposed for specific control situations.

9.3 ALLOCATION O F FUNCTIONS T O M A N A N D MACHINE The process of determining those functions to be assigned to the human operator in avionic systems is termed crew analysis2. The allocation of functions to the system or to the human operator is a process which is most important to ultimate system effectiveness. The allocation must be established early in systems design, prior to hardware constraints, and according to established principles of allocation. Subsequent modifications are inevitable, but the process is designed to accommodate changes. In multi-crew avionics systems, allocation of functions among crew positions is of extreme importance, particularly due to avionics integration and the inherent flexibility of computer-serviced displays. The following are the main points that should be considered: (a) (b) (c) (d) (e) crew workload, crew skill, communications among crew positions, hand-off of functions from one position to another, possible crew contribution to reliability through primary and secondary crew function allocations.

In a single-piloted advanced aerospace vehicle, the proliferation of controls and displays will demand a considerable level of occupation by the pilot. In the case of a high performance fighter, additional complications include low-altitude flight and supersonic speeds requiring a highly discriminating and rapid target acquisition capability in the diverse environments of geography and weather, both day and night.

144
i

A system designed to serve the complex needs of an advanced tactical fighter may be expected to be vulnerable to equipment failure and battle damage, jeopardizing flight safety and/or mission success. The analytical approach used to develop a cockpit concept for the next generation of tactical fighters has been described in the literature3. The man/machine interface for vehicles and other process control, utilizing computers, multiprocessors, multiplexers, dedicated sub-system processors, sensors and effectors has also been described in literature4 including the specific case of the space shuttle orbiter5. 9.4 ESTABLISHING REQUIREMENTS FOR INFORMATION, DISPLAY AND MANUAL AND AUTOMATIC CONTROLS An integral part of the process of opimizing the man/computer interface is the detailed determination of the information required by the man and categorization of his response. This information is utilized for the specification of control and display requirements for the computer interface. The lack of due consideration of the information required (and its format level) for the operator to make the transition from a monitoring stage to more active involvement as a system effector is a very common pitfall in man-machine interface. Chapter 8 treats this subject at length. 9.5 DESIGN OF THE MAN-MACHINE INTERFACE Data regarding the exact content and format of the information required for transition from one mode to another must be available to design engineers early in the process to influence preliminary design and design tradeoffs. The design should also reflect the human factors considerations to ensure that the design is not compromised in that respect. It also is necessary to separate design for normal operation from design for degraded and contingency modes of operations. Normal operation design divides into design of procedures, message language and format and following that design of hardware by means of which messages will be interchanged (survey of hardware means available and desired). Design for cases of mulfunction has to cater both for continuation of operation when the system is unable to carry out all of its tasks so that the human has to take over some of them or parts of them, and also if possible the provision of means whereby humans can diagnose and repair malfunction while continuing with limited operation. Here it is much more difficult to foresee and work out procedures for all eventualities and it must be assumed that an attempt to do so will not be fully successful, hence the importance of providing means for interchange of elementary message building blocks and extensive information on malfunction so as to enable the human to build up what he may require from the basic elements. The preliminary design of the man-machine interface is impacted through the trade-off study process. The design will undergo change as a function of (a) any change in the allocation of function to the computer, system, or to the crew, (b) any change in apportionment of function to a specific crew position, or (c) any change required to permit the human to perform a function that has been demonstrated to be deficient in meeting one or more functional requirements. The interactive nature of the method permits modifications to occur, provided the outputs are phased properly in time2. Of course, it may appear hard to ask someone who had just finished spending a great deal of time and effort on designing something to wrench himself away from what he has just done and to consider alternative approaches. It must, however, be pointed out that in producing a design the designer has learned a great deal about the problem and the means of solving it, and is very much wiser than he was at the outset, so that he has reached a stage when he can have an overall view of the whole problem and is in a position of seeing and evaluating alternatives. If there appears to be a more attractive alternative, this has to be worked out in comparable detail and this may have to be done more than once. Once it is decided which alternative to adopt, an internal optimization within this alternative has to be carried out considering the various possible trade-offs from the point of view of the various criteria applicable to that particular system. These will normally include reliability, availability, integrity, cost, cost effectiveness, weight, and space. The requirement for flexibility and growth potential must be considered in man/computer design. This means the anticipation of future requirements and the modification of existing functional requirements. When choosing a display and control interface for the digital computer through trade-off and control interface for the digital computer through trade-off study - the growth capability of the software and display hardware must be considered. The capability of the human to use additional information or to assume additional functions must be evaluated as well. Finally, simulation and operational tests should be performed to check: (1) whether the design achieves the objectives, i.e., whether the system will perform the tasks which it is designed to do by the combination of tasks of the system and human; (2) whether the system is capable of presenting all the information which may be required with a satisfactory response time;

145

(3) whether the information is presented in a form which will enable the human to digest and use it for decision making, and then communicate that decision to the system within available time limits. If the design is viable, the next step is to see how well it meets other criteria, e.g., cost, reliability etc. 9.6 EQUIPMENT FOR MAN-MACHINE INTERFACE The first and simplest devices for enabling the operator to communicate with the system were switches and push buttons. Signals from the system to the operator were given (and still are) by lighting up lamps or sounding an audible alarm. An extension of the push button is the keyboard. Keyboards used with real time systems do not normally have a typewriter layout; the keys are usually arranged in alphabetic or numeric order. An example of an alphanumeric keyboard is shown in Figure 9.1. A further stage of development came with the introduction of functional keys, in which case a single key transmits a complete message. This in turn led to the so called programmed function keyboard. With this device the message which any one key transmits to the system is changed by the system itself as required; since at any one stage in the operation of the system certain messages may be relevant while others will not be required. With this type of device some means for indicating the particular function which is assigned to a given key at any one time is required. An example of a programmed function keyboard used in an air traffic control system is shown in Figure 9.2. A far more flexible programmed function keyboard can be achieved with CRTs. One type of CRT based programmed function keyboard is known as a touch-wire. It consists of a CRT display with some 16 to 64 wire ends fixed on the implosion screen. The function appropriate to the particular wire end at a given point in time is displayed above that particular wire end. In order to communicate one of the available functions to the system, the operator simply touches the appropriate wire; hence the name touch-wire. An alternative implementation is the digitatron. This has 8 light-beam sources along, say, the right hand edge of the CRT with 8 photocells opposite them along the left hand edge of the CRT. Similarly there are 8 light-beam sources along, say, the upper edge of the CRT with 8 photocells opposite them. The user's finger at any one of the 64 beam interaction points will intermpt 2 of the 16 light beams and inform the system that the user has chosen one of 64 possible functions displayed to him. An example of the possible sequences of sets of functions displayed on a touch wire in the case of an air traffic control system is given in Figures 9.3. to 9.7. In this particular system only twelve wires were used superimposed on the bottom end of a graphic display as illustrated in Figure 9.3. CRT displays are nowadays widely used not only for the display of messages made up of characters, but also for the presentation of graphic information. One method used to reduce the load on the system when dynamic graphic information is to be superimposed on static information (or on information which varies comparatively infrequently) is the rear port projection tube. These are CRTs which have on the rear of the tube, next to the neck, a built-in slide projector. With such a tube the static information is projected onto the face of the tube optically. A typical use of such a tube in an ATC system would be to project optically the relevant map of the airways and navigational aids while the symbols representing the position of the aircraft would be generated electrically by the system. Color is now also being introduced into CRT displays for real time systems. One way of doing this is to use a television type triple-gun tube. There is, also another type for use in real time systems known as the penetron. This is a single-gun tube with a double layer of phosphor, the outher layer being green while the inner one is red. The greater the speed of the electrons hitting the screen the further they penetrate towards the green layer. Thus by varying the acclerating potential a range of colors between green and red can be obtained. When graphic displays are used, means are also usually required to enable the operator to specify to the system any desired point on the display. The three main methods used for doing this are the light-pen, the joy-stick and the rolling-ball. The first of these is the most widely used in general, but it is not normally used in avionics and associated real-time systems. It operates by picking up the light-spot generated on the particular point of its CRT. The joy-stick works on a different princple in that it is used to move a special, easily recognizable symbol on the CRT. When this special symbol is in the position to be designated to the system, the operator pushes a so-called entry button thus informing the system that this is the identified spot. There is a version of the joy-stick which does not require moving the stick and where the spot is moved across the CRT just by pushing the stick in the direction in which it is desired to move the spot. The rolling-ball operates on a similar principle but in this case the operator's instrument is a billiard ball, largely embedded in the operator's working surface. The special spot on the CRT is moved as the operator rolls the exposed part of the ball with his fingers. No practial method is as yet available which enables the system to recognize spoken messages. Audio communication to the human has however been employed, by means of messages assembled by the system out of prerecorded words. This method is currently in experimental use in an air traffic control system generating messages from the system to the pilots of controlled aircraft.

146

ERROR CLEAR
m.iiimMiW|

'MW.'V.Wl

vv

i ii'r"u'i\W\v^3

B C

D E

F
L

3 6

ENTER
pU.mM-.MVA

BACK SPACE! _a_H_i_a

" 'w\

immnv:

H Kotam

5K

PMHl

N 0

P Q

7
LEFT ALPHA
iwmwmm

S
RIGHT ALPHA

. VMKV. MV.

- A

V
X Y

V w
^a ANK

Fig.9.1

RBDE-5 alpha-numeric keyboard

r
SELCT CATEG S SIM BESSZSESa T TRACK

Simulation Category

Track Category

M Hold Category

MODIF Q HOLDL K HNDOF BEE2._r_S_l D DPLAY

r^
p^\i

M o d i f y Category

Handoff Category

Display Category

D F G / C C C Category

m
v_
8_5_8
Fig.9.2

c
CRDEV F DF/CC DEC ^VIP_ED VSiSma\}f^ilA

,;^-- ? x

CRD Category

in

DFG WIRED Category

Select category display

147

Touchwires Fig.9.3 Function control by means of touchwires

HVT HVR CFL RESET .

= =

HANDOVER TRANSMIT HANDOVER RECEIVE CLEARED FLIGHT LEVEL STEP BACK TO START OF PREVIOUS PAGE

HVT

ACT

LBL

CON

CFL HVR

*etSEL

-tftt
QL

RESET

MOVE

HVT, CFL & HVR ADDED Fig.9.4 Action page including handover and CFL options

148

N,S,E,W WHERE N S E W LEA RESET

= QUADRANTS FOR LABEL POSITIONS RELATIVE TO SYMBOL - ABOVE = BELOW - TO RIGHT OF = TO LEFT OF - LEADER = STEP BACK TO START OF PREVIOUS PAGE

N W LEA E RESET

SEQUENCE TERMINATES O N TOUCHING N , S, E OR W

Fig.9.5 Position page

0-7 A

RESET

= NUMERALS FOR USE WITH S.S.R. CODES USED IN LIEU OF 3rd and 4th FIGURES OF S.S.R. CODE FOR SELECTION OF N O N DISCRETE GROUP * STEP BACK TO START OF PREVIOUS PAGE

RESET

FOUR STEP PAGE

Fig.9.6 Code page

149

A B D SUP RANGE TRL RESET

= = =

S. S. R. mode A S.S.R. mode B S.S.R. mode D CALL UP SUPERVISOR START PAGE INPUT MAXIMUM DISPLAY RANGE REQUIRED TRAIL DOTS STEP BACK TO START OF PREVIOUS PAGE

SUP TRL
RANGE RESET

SINGLE STEP PAGE

Fig.9.7 Controller start page

150

CHAPTER 10 NOVEL DEVICES AND TECHNIQUES E. Keonjian 10.1 INTRODUCTION

During the last decade, considerable advances have been made over the whole range of avionic devices and techniques. These novel devices and techniques, have been finding their way into avionics systems, making them more effective in terms of reliability and operational capability; coupled with simplicity and lower cost for maintenance and ownership. This process has been accelerated particularly by the rapid progress in microelectronics, with its far reaching consequences especially for future avionic computer systems. In this chapter we will review some advanced devices and technologies still in development, which, when matured, could further improve the effectiveness of avionic computer systems. 10.2 LSI TECHNOLOGY

The concept of Large Scale Integration (LSI), offers new and exciting possibilities for avionic computers. Coupled with automated intercommunication techniques, this concept permits not only unique circuit combinations, but also lower hardware cost, increased reliability, and improved overall system performance. Below are some LSI definitions which have been established in this field since the beginning of 1970. The term LSI commonly refers to a technology which permits the integration of a large (conventionally, over 100 equivalent gates) number of electronic devices, such as diodes and transistors into one single functional package such as a shift register, multiplexer, decoder, counter, etc., built normally on and within a single semiconductor chip or wafer1. Figure 10.1 illustrates such a circuit, Intel Model 1402 Four 256-bit MCS Dynamic Shift Registers. In addition to characterizing LSI microdrcuits by their complexity, they can also be characterized by the technology or device structure (Bipolar versus MCS), and by the interconnection technique (discretionary wiring versus fixed wiring approaches). In bipolar devices the conduction takes place by the flow of both holes and electrons as in the ordinary p - n junction transistor. As opposed to this, in MOS devices the conduction is due to a single type of carrier, either holes or electrons. These devices are also called the field effect devices, or FET, because the modulation of carrier flow is due to an electric field. When the field is across an oxide layer at the semiconductor surface, the device is called the metal-oxide-semiconductor, or MOS. Figure 10.2 illustrates the cross section of bipolar and MOS structures. There has been a considerabl discussion on the relative merits of these two basic types of LSI devices. Rather than to add to this "controversy", the reader is directed to the available corresponding literature, especially to AGARD's Lecture Series No.40 (Ref. 2). In general, bipolar devices offer relatively high speed and greater "drive" capability. The MOS devices on the other hand are less expensive in manufacturing, can be made in smaller stmctures and hence a more dense package can be easily derived. In addition, it is possible to use MOS transistors as resistance elements and a number of functions can be physically implemented in MOS forms using fewer circuit elements. Complimentary MOS (CMOS) - MOS LSI circuits can be made to incorporate both P- and N-channel devices on a chip. These circuits dissipate power only during a change of state. The instant of change is the only time that significant current flows and this current can be kept extremely low, on the order of a few microamperes. Along with low power consumption, CMOS also offers greater speed than conventional MOS circuitry. CMOS also has good noise immunity characteristics and a strong insensitivity to supply voltage variations. Two extra masking steps however are required in CMOS fabrication: one step to add the N-channel transistors and another to electrically isolate them from the P-channel devices. Contamination precautions must also be more elaborate with CMOS devices because of the high sensitivity of N-channel transistors to contamination.

151

Fig. 10.1

Intel model 1402 four 256-bit MOS dynamic shift registers

152

P BASE INSULATION SECOND LAYER METAL

FIRST LAYER METAL

THERMAL OXIDE

RESISTOR

N EPITAXIAL LAYER ISOLATION REGION BURIED LAYER N SUBSTRATE ISOLATION REGIONS

METAL INTERCONNECT

N SUBSTRATE

DRAIN

GATE OXIDE

SOURCE

Fig. 10.2

Cross section of bipolar and MOS structures

153 Below are the definitions of two basic wiring techniques. Discretionary Wiring A technique which permits the selective interconnection of only good cells on the chip, bypassing the defective units. The layout for such interconnection paths is generally computer programmed and generated. Each cell is a complete basic circuit (a "building block") with pads for preliminary probing. This means that there is no efficient usage of potentially good silicon material. On the other hand since the interconnection patterns required connect the large probe pads only, it is not necessary to have high resolution masks. To simplify routing of the interconnections, two additional levels of metallization are required. The discretionary wiring approach is capable of producing a wide variety of functions within a short time at low design but relatively higher manufacturing costs. Fixed Wiring - (Or the "Chip Approach") - A technique whereby identical chips are used across the wafer, each chip with complete identical interconnection patterns regardless of fault location. Since there are no probing pads provided for each cell, a higher circuit density (and hence a more efficient utilization of silicon wafer) can be achieved. Test pads are provided only for input-output access to the circuits: therefore the circuits cannot be readily tested until fabrication has been completed. The fixed wiring approach requires greater design time and cost and much higher resolution masks, but is capable of producing quantities of components relatively inexpensively. Between discretionary and fixed wiring approaches, there are various compromises which tend to optimize the manufacturing cost of circuits for a particular application. Typical examples are: Micromatrix - (Per Fairchild Semiconductor Corporation) Using standard cellular arrays, complete, except for metallization of interconnections each array consists of a predetermined matrix of component pattern cells which may be interconnected to form the required custom circuits. In addition, each cell may be individually customized by cell interconnections to become one of a variety of building blocks, such as AND-OR gates, flip-flops, etc. Polycel (Per Motorola Semiconductor Company) Very similar to micromatrix, and geared more toward computer aided design - this is also called "Master Slice" or "DRA" (Discretionary Routed Arrays, per Texas Instruments, Inc.). Below are a few new promising techniques in LSI technology: Nitride Passivation - The use of silicon nitride instead of silicon oxide as the gate/channel insulating layer resulting in low threshold voltages. The protective properties of nitride passivation may make the hermetic chip a reality. Silicon Gate - MOS technology using highly doped silicon instead of aluminum for the gate electrode. In fabrication, the number of masking steps are the same as in conventional MOS but in etching the oxide over the source and drain, the polycrystalline silicon acts as a mask, preventing the gate oxide from being etched. This results in a predsdy-formed, self-aligned gate. Silicon gate technology allows low thresholds compatible with bipolar devices, higher component density, higher speed, and the fabrication of MOS and bipoloar devices on one chip. Field Shield - Self aligning passivated MOS process allowing bipolar speed compatible with N-channel devices. It also results in very low threshold and extremely high field inversion voltages. Ion Implantation - A method of doping semiconductors using a high energy (90-300 Kv) accelerator to drive the dopants into the bulk silicon - using a focussing mechanism the accelerator selects by mass the dopant to be used emanating from an Ion source such as boron trichloride or boron trifluoride. Ion implantation is a faster process than diffusion and can be done at room temperature. It lowers device capacitances allowing higher operating speeds. In addition, Ion implantation lowers device thresholds while delivering a high ratio of field oxide to device threshold. The above mentioned and other new techniques have already introduced many innovations in the processing of bipolar device. However there has been improvement also in MOS technology, such that the overall size reduction remains in favor of MOS, while speed/power figure of merit remains in favor of bipolar. What about the application of LSI devices in advanced avionic computers which we will call "the 4 t h generation" of digital equipment? In such equipment, where LSI is used primarily for memory and logic function, LSI offers not only a reduction of size and power consumption of the equipment, but it also offers a choice between a single large central processing unit and a number of smaller special purpose units scattered about the air or space craft. We have barely touched upon the great versatility of LSI devices. Their use for computer memories, displays and other avionic applications will be discussed briefly, further in this chapter. However the maximum benefit in avionic system design with LSI, will depend on the trade-offs of hardware versus software, remembering that system software is a generally more complex entity than processor logic, and is usually not debugged until

154

long after the hardware is complete. Considerations such as reliability and maintainability will also enter into the picture to make the final decision in favor of LSI more complex. Nevertheless, the era of LSI is here. It has been used as a building block for many advanced avionic systems and its pace of acceptance will be accelerated for years to come. 10.3 SEMICONDUCTOR AND OTHER TYPES OF MEMORIES

Semiconductor technology has an inherent advantage over many other types of technologies for computer memory, that it lends itself rather easily to batch fabrication on single large chips. Semiconductor storage elements have already superseded magnetic films in fast scratchpads. Figure 10.3 shows a photograph of a high density, fixed wiring, 256-bit, random access memory using MOS technology. The central portion of the chip contains the memory array while the buffer, decoder and drivers are located around the outside, which permits the utilization of a single 16-pin package. A bit-organized, 16-bit silicon chip compatible with TTL logic is already commercially available. The chief dimensions: 225 x 225 mils., power dissipation: 250 mW, access time (with a 30 pF load): 20 nsec. The chip has a self contained driving, sensing and storage circuitry, which permits optimization of overall circuit design and provides the system designer with a considerable flexibility. Figure 10.4 illustrates the Intel 1024-bit dipolar Read Only Memory. Low-power dissipation (0.1 mW per cell, steady-state) MOS memory circuits for the aerospace application, has been described in the literature3. Using high performance drivers and RC networks to simulate an 8K bit array, the memory is estimated to operate at 12 ns access, 35 ns read cycle, and 60 ns write cycle, with a system dissipation of 43.5 watts. Beam lead transistors are especially suitable for extremely small size memories. A 30 x 38 mils stmcture was achieved containing 16 cells, which corresponds to 95 bits per square inch density. The memory system constructed of these chips, is a 64-word, 16-bit system which operates with a 100 ns read-write cycle time. In general, large arrays of semiconductor cells, using present day semiconductor technology, require line currents comparable to those in core. Anticipated advances in the lowering of MOS threshold voltages plus the use of two layer metal indicate the possibility of power levels less than in core. As to the volatility of semiconductor memory, use of a back-up storage invalidates this problem, to a degree. Semiconductor technology has an inherent functional advantage over magnetics in Content Addressable Memories (CAM), namely that the former can be searched in a bit-parallel as well as a word-parallel mode, i.e., all bits in each word can be interrogated simultaneously. Magnetic CAMs have an inherently poor signal-to-noise ratio due to the considerable variability in analog sense signal from element to element and, as a consequence, tend to be limited to bit serial operations. In addition, large semiconductor retrieval-type CAMs (in the several thousand word and larger category) are more economical than similar magnetic CAMs. In read-only memories, one of the significant approaches today lies in the use of permanent MOS techniques. Fixed a-rays of typically 1024 bits are now available, with about two microseconds access time. The economical advantage stems from the fact that only one mask operation must be specified by the user. The likelihood of future improvements in MOS speed is good, and for this reason, its wide use in micro-programming can be anticipated. What are the more advanced concepts in semiconductor memories? The following is a partial listing of some of the new developments. (1) Two-terminal Transistor Memory Cell using breakdown. This is a transient charge storage memory cell utilizing a two-terminal transistor structure and junction breakdown. (Bell Telephone Laboratories.) (2) A High Performance N-Channel MOS-LSI using Depletion-Type Load Elements. A 2048-bit read-only memory with 300 ns access time and 50 microwatt per bit power dissipation has been achieved by Hitachi Company of Japan. (3) A Switched Collector Impedance Memory - This is a 288-bit LSI in which integrated bipolar memory cells exhibit 4 ns access time at 50-200 microwatt-per-bit cell standby dissipation. (Hitachi, Japan.) (4) A trim memory employing both NPN and high-gain Unijunction Transistors. A three photo-mask flipflop memory cell showing a cycle time of 500 ns has been achieved. Each cell contains four devices in an active area of 35 sq. mil and uses 40 microwatt-per-bit holding power. (Bell Telephone Laboratories.)

155

Fig. 10.3

Intel 1024-bit dynamic MOS RAM

156

Fig. 10.4

Intel 1024-bit bipolar ROM

157 (5) Small-Size, Low Power Bipolar Memory Cell has been developed by IBM, which allows a very high storage density in random access read/write monolithic memories at an extremely low power dissipation. (6) A large, static MOS/bipolar ROM with combinatorial addressing for keyboard encoding has been developed by Honeywell and Texas Instruments, Inc. It is a simple monolithic LSI device with 5520-bits, bipolar TTL compatible outputs. (7) An integrated, fixed-address MOSFET Memory Cell with normally-off-type Schottky-barrier FETs, has been developed by IBM. A 1 micron-channel length and contact separation provide high package density (2.5 mil2/cell) and high speed. Supply voltage can be below 1 V. (8) In the area of monolithic main memory, IBM has reported development of a 128-bit bipolar memory chip with under 50 ns access delay at 0.5 nW per bit and with wide fabrication tolerances. Also the design, process and characterization of a bipolar main memory, with a basic 512-bit module containing four chips with decode and sense circuits, has been reported. (9) A fully decoded 2048-bit electrically programmable MOS-ROM has been developed by INTEL Corp. The memory element is a silicon gate chip that provides access times of 500 ns (dynamic mode) or 800 ns (static mode). (10) Some other interesting developments have been reported recently. Among these are: (a) A latent image memory (by IBM) which is a random access read/write memory with a suppressed read-only image. The ROM image is non-volatile, reappearing with each powering-up and virtually no effect on the orginal RAM capabilities. (b) Charge-transfer electronics - tandem matrix semiconductor memory selection, using one Schottky and two PN diodes per selected matrix rail. (Bell Telephone Laboratories.) (c) A self-contained Magnetic Bubble-domain memory chip - consisting of NDRO shift register loops, generators, input and output decoders all implemented with double domain devices - and magnetoresistive detectors, has been reported by IBM. (d) A memory system based on surface-charge transport structure, in which adjacent rows propagate in the opposite direction, has been combined with compact refresh-turn-around circuits to produce a shift register memory system of high density and speed, has been reported by General Electric Co. (e) A new planar distributed device based on a domain principle, able to perform many processing functions such as analog multiplication, signal correction, coordinate transformation, and analog-todigital conversion was reported by Tektronix, Inc. (0 Magnetic film memories, making use of a truly planar single film element with an open-flux structure. The elements usually possessed a relatively low ratio of disturb-to-full switch threshold, and also require a rather low element density to avoid interactions between adjacent bits.

(g) An important extension of the above concept is MATED-FILM Solid Stack element, in which the word line plane is orthogonal to the bit line plane. (h) A plated wire matrix is formed by means of an orthogonal arrangement of plated wires or bit lines and an overlay of copper strap word lines. The bit is at the intersection of wire and strap. This concept proved to be attractive for low power and mass memory applications, as well as main memory. (i) Advances have been reported in optical beam addressed schemes and a number of read/write schemes using various magneto-optic media have been proposed (see References 4 and 5). The progress in laser technology makes this scheme rather promising. The sonic deflector seems to be the more practical deflection method at present. It has been estimated that using such a deflector, a 108 bit semi-permanent memory is technically feasible. (See References 6 and 7.) Magnetic Bubble Memories. The basic storage medium is a cylindrical region of magnetic energy called a domain or bubble. It is a whole new class of mass storage, which promises up to a 100fold improvement in access time over disks as well as asynchronous, multi-speed operation for greater flexibility. The principle development efforts have been aimed at devising the best methods for manipulating these domains and in formulating magnetic materials that provide optimum performance. Several suitable circuit techniques for manipulating domains have emerged, but device development has been delayed by the search for suitable materials, which still remains the most difficult area. The potential applications for bubble memories are many. They range from fast-access memories (FAMs) to a repertory dialer for telephones.

(j)

158 The immediate and most frequently feasible applications for bubbles will probably be in the replacement of small disc memories. Bubble memories on the order of 1 to 10 million bits are very attractive because they are economical. The table below, compiled by Dr P.Bailey of Monsanto, shows the comparison of various types of memories8. TABLE 1 Tape Cost/bit i Average access time-sec. Bits/in2 Power consumption: Joules/bit Volatile Logic* Radiation resistance * ** 10.4 LSI TESTING 1(T4 10 104 10"4 No No Fair Disc Drum l(T l Core 1 10"6 103 10"' No No Fair
i

Si

rc

Bubble 104 10"s I0 6 lO"13 No Yes Fair**

io- 2
105 10"4 No No Fair

io- 7
10s 10"9 Yes No Poor

Capability of combining logic and memory operations in the same device. Based on preliminary data. More tests are required.

Due to inherent complexity of modern LSI devices, exhaustive testing of all functional and individual parameters may require several months to complete, even if the duration of each test is reduced to as little as 10 microseconds or less. Therefore, a full family of a new generation of LSI testers, a very complex machine, was born and the algorithms have been developed to simplify the testing procedures of LSI circuits. Figure 10.5 shows the system configuration of the Microdata MD-200 MOS tester. Functional and parametric testing comprise the two general areas of LSI testing. LSI electrical testing is a particularly problem ridden area due to high chip complexities, limited internal chip access, a proliferation of custom logic, mixtures of sequential and combination logic, the continual evolution of new technologies (e.g., CMOS, Field Shield, ion implantation, silicon gate, etc.) and a lack of uniformity throughout the industry in testing of LSI devices. 10.5 FUNCTIONAL TESTING
r

Functional testing of LSI microdrcuits comprises the generation of specific test patterns which, when applied to the input terminals, will yield information indicating the presence or absence of faults in the device. These test routines are generally classified as either fault diagnosis or fault detection routines. Fault diagnosis includes the location and determination of the fault, while fault detection is, in general, the verification of the Boolean response of the device. Assumptions usually made in functional testing include the following: Faults can only occur one at a time, Faults are static, not intermittent (i.e., stuck at 1, or stuck at 0), Logic is non-redundant. Functional testing is also categorized according to the type of logic to be tested. The logic type is either combinational or sequential. Combinational logic networks respond to each input pattern independently of the previous input. Sequential logic networks respond according to their present state and the incoming input pattern. As a result, sequential logic testing is more complicated than conblnation testing. Sequential test routines, however, often include a capability for testing combinational logic4. It is well known that the application of all possible combinations of input patterns to a device for functional testing is not at all practical, particularly with complex devices. Additionally, in as much as most LSI microdrcuits are usually pin-limited, it is often impractical if not often impossible to provide sufficient external test points for monitoring the performance of internal circuit elements. The singular prohibitive factor in this exhaustive testing concept is time. As a result, algorithms have been developed outlining more efficient test approaches that will

CONSOLE INTERROGATOR UNIT PARAMETER TESTING (1) ASR 33 PATTERN ANALYZER PATTERN SYNTHESIZER (1) CONSOLE H.S. PAPER TAPE HEADER/PUNCH

1
MAIN MEMORY ^ MULTIPLEX CHANNEL 1 1 DIRECT MEMORY ACESS CHANNEL PATTERN SYNTHESIZER (4)

INTERROGATOR UNIT

PARAMETER TESTING (4) CONSOLE

CARD READER DIRECT MEMORY ACCESS CHANNEL DISC.

INTERROGATOR UNIT PARAMETER TESTING (13)

CONSOLE INTERROGATOR UNIT PARAMETER TESTING 116)

MAGNETIC TAPE

Fig. 10.5 System configuration MD-200 (Microdata)

160 sufficiently exercise a device. In the area of LSI testing, this lends itself to more than one discipline of thought. One testing philosophy dictates that all gates shall be exercised at least once, while another approach is to exercise most of the gates several times. In the latter technique, a grading system is used to grade each test sequence according to how many gates were exercised. Testing sequences can be combinations of all 1 's followed by all 0's or alternate l's and 0's (checker board array) or some other variation of binary elements. In functional testing, it is desirable to have a test system that permits a variable allocation of input and output pins and which also possesses the capability of changing all inputs at once. This allows testing flexibility from device to device and permits testing of various I/O pin configurations with maximum binary exercising. The length and configuration of data patterns depends on the type of device to be tested. In general, the various LSI devices fall under the classifications of Random Access Memory (RAM), Read Only Memory (ROM), Shift Registers, and Logic Arrays. ROMs require a pattern depth of 2^ , as a minimum, where N is the number of address lines. RAMs require relatively long, yet simple data patterns (e.g., write l's, write 0's, write checkerboard) and it may be desirable to use self-generating pattern techniques to produce the large words required. The testing of Shift Registers requires propagating a logic 1 through all existing logic 0 stages and vice versa. Random logic arrays require the generation of special complex patterns. 10.6 PARAMETRIC TESTING - DC AND AC

Electrical parameter testing of LSI devices fall into two general categories: DC or static parameters measurements, and AC or switching characteristic measurements. Parametric tests relate directly to process verification and as a result are a mandatory part of LSI device testing. Test time for individual parameters is much longer than functional test time. This is due to the setup time required for each parameter along with proper sequencing of current and voltage measurements. Some useful parametric information may be derived through exhaustive worst-case functional testing where functional test patterns are applied to the device under test (DUT) for various worst-case input or supply conditions. Verification of electrical parameters is inferrred by the realization of a correct output sequence for all worst-case situations. The "functional" parametric testing is faster of course, since measurement time is eliminated. The extent of AC testing should be related to the intended utilization of the device. Switching characteristics of devices should be verified at as close to the designed operating speed as practicable. Characterization of circuit parameters is, at best, a compromise of proper testing procedures. For very high-reliability applications, neither bipolar nor MOS-LSI processing technology is controlled sufficiently to allow ambient temperature characterization of DC parameters to preclude actual testing of the device under temperature or speed extremes. 10.7 OPTOELECTRONIC DEVICES

Much literature exists in the fast growing field of opto-dectronics. The purpose of this chapter is to give a brief "account" of a few significant and promising developments which are finding their way into advanced avionic computer systems. Opto-electronic devices as practical operating components are less than a decade old. Yet their application to computer systems ranges from optical computer-tape and card readers to optical computer keyboards, and from simple panel indicator lamps to complex alphanumeric displays for radars, computers and aircraft instmmentation, including devices with a built-in storage capability. Solid-stage opto-electronic devices represent a special interest to computer designers in view of their relative simplicity, high reliability, and compactness. Semiconductor - light (and IR) emitting diodes are playing a significant part in the rapidly growing field of opto-dectronics. They are designed into equipment such as card readers, encoders, and night vision systems. A GaAs IR-emitting diode in a pn junction diode, which can emit photons with energy slightly less than that of the semiconductor band-gap. With forward bias, light is generated at the junction and is emitted in all directions. The devices can be operated in either continuous or pulsed mode. A typical application: card readout. GaAs Laser Diode The GaAs injection laser is basically a planar p - n junction in a single crystal of GaAs. At low values of forward diode current, it functions as a conventional GaAs IR emitter. However, if the laser is pulsed beyond a threshold current, lasing occurs and a marked increase in radiant power is produced. There has been an extremely large literature published on the fundamentals of lasers and GaAs IR emitting diodes, which eliminates the necessity of further discussion of this subject in this chapter.

161

Photosensors There has been a whole family of photosensors developed throughout the industry in recent years. The use of photoconduction in junction silicon devices dominates the present technology. The devices include photodiodes, phototransistors and multijunction photosensitive units, such as light activated SCRs. (Photoswitches.) Silicon FET are the most sensitive devices because of their relatively high input impedances, which permit generation of high control voltage from small photocurrents. Optical Couplers A host of new components called optically coupled isolators have appeared in advanced computer drcuitry, consisting of a combination of an IR light emitting diode and a photosensitive transistor. The great advantage of such an optical coupling is an almost perfect isolation between the input and output terminals (typically 10" ohms). An interesting application of opto-dectronic devices can be found in solid state DPDT relays utilizing an electrooptical isolation. The circuit has two pairs of NPN transistors; one pair normally conductive so as to provide openings in current paths to terminals connected to its collectors. Switching action is obtained by means of a photon-coupling pair (photo transistor and light-emitting diode) connected through other-transistors to the bases of the PNP transistors5. Real Time Displays for Airborne Image Forming Sensors; Laser Beam recording and display, and many more topics related to opto-electronics can be found in the AGARD Conference Proceedings No. 50, devoted entirely to the subject of Opto-Electronic Processing Techniques. What is the state-of-the-art of light-emitting diodes (LID)? Because of the wide variety of structures used for LEDs, the external efficiency for identical material can vary greatly from diode to diode, depending often on the ingenuity of the investigator in fabricating the device. Below is a summary table which compares the reported effidency and brightness of various LEDs6. TABLE 2 State-of-the-art Performance of pn Junction LEDs
Peak Wavelength A 6900 6750 6600 6170 6100 6100 5900 5700 5500

Material

Commercially Available? Yes no yes no yes no yes no yes

Color

Lum. Eff. Lumens/Watt 20 a 16 42 284 342 342 515 648 677

^ext* Percent 3-7b 1.3 0.5 0.1 0.013 0.04 0.003 0.02 0.5-0.6
b

B/J,t Reference fL/A-cnr2 350 c 140 145 31Crd 35 40-1006 10 115 470
f

GaP: Zn,0 Al. 3 Ga. 7 As GaAs. 6 P. 4 ln. 42 Ga. S8 P GaAs. 5 P. s GaAs. 2 5 P. 7 5 :N SiC ln. 4 Ga. 6 P GaP:N

red red red amber amber amber yellow yellow-green green

29 38 32 36 33 44 34 6

a b c d e

Except where noted, efficiencies for diodes with plastic encapsulants. Except where noted, B/J calculated from Equation (2) using efficiency for unencapsulated diode with (A:/As) = 1 . Diode efficiencies assumed to be 2.5 times less without encapsulation. Mean value for nonmonochromatic emission spectrum. Range between commercially practical and best laboratory results. Assumed 3% unencapsulated diode efficiency; (Aj/Aj) assumed to be one third to compensate for significant edge emission. B/J calculated from measured efficiency value of 5.9 x 10 r4 for unencapsulated diode. Typical values of B/J reported as 40 to 60 fL/A.cm-2 in Reference 33. Value of 100 fL/A.cm"2 calculated from Equation (1) using efficiency value found in Reference 33. Calculated for representative dc efficiency of 0.1 per cent for unencapsulated diode. (Aj/Aj) assumed to be one third. From: IEEE Spectrum. May 1972, pp.28-38, "The Future of LEDs" by C.J.Nuese. H.Lressel, l.Ladany.

162 REFERENCES
1. 2. -

AGARD Lecture Series No.40, Large Scale Integration in Micro-Electronics, July 1970. AGARD Lecture Series on Air and Spaceborne Computers, 1968, AGARDograph No. 127, pp.113-126. Microelectronics in Perspective, Keynote Address, 1967 WESCON Symposium, San Francisco, California. Magneto-Optic Variable Memory, J. Appl. Phys., p.1110, 1965. A Proposed Beam Addressable Memory, IEEE Trans. Mag., p.72, 1967. A Review of Acousto-Optical Deflection and Modulation Devices, Appl. Opt. 5, p. 1629, 1966. Design Considerations for a Semi Permanent Optical Memory, BSTJ.46, p.1267, 1967. It's a Year for Bubble Memories; Prototype will Appear Shortly, Electronic Design 3, 1 Febmary 1973. Amorphous Metallic Films Promise Easy-to-Make Bubble Memories, Electronic Design 5, 1 March 1973.

3. Keonjian, E.
4. Chang, J.T. 5. Mee, C.D. Fan, G.J. 6. Gordon, E.L.

7. Smith, F.M. Gallaher, L.E

8. 9.

163

CHAPTER 11

SPECIFYING THE REQUIREMENTS A.L.Freedman

11.1

PRACTICAL DEFINITION OF SYSTEM

Many books have been written on the subject of System Engineering but no satisfactory definition of the word system has apparently materialised so far. The fifth chapter of this book is in fact devoted to the elucidation of the nature of real time systems and begins by pointing out the distinction between closed and open systems. The point is made that the latter are really characterised by the purpose which they serve. It is in fact from the consideration that an open system is there for a given purpose that one may derive a definition of the word system. It will be noted that the word is used in a great many contexts, not necessarily technical ones. Thus, for instance, we speak of a system of taxation or of an educational system. Considering this latter example one knows that the educational system could be sub-divided into a system of primary education, secondary education and so on yet we still talk about these components as systems even though they are only a part of a larger system. Note, however, that this is only tme as long as the part of the larger system is a complete means for achieving its purpose. Thus for instance we would not refer to the set of all primary teachers as an educational system. Taking a very simple technical example, note that one would not talk about a hammer as a system; one would, however, regard a hammer and nails as a system for fixing together certain items. Hence one concludes that an open system is a complete tool for the performance of a given activity. The first section of Chapter 5 also brings out another basic principle of system engineering namely that open systems are hierarchical. On the one hand a system may itself be made up of a number of sub-systems while on the other hand the system as a whole is a sub-system of another, higher level system. Since an open system is there for the purpose which it serves, its essential definition can only be expressed in the terms of this purpose and this purpose is part of the next higher level in the hierarchy. Thus for instance a definition which embraces all the possible varieties of tables is only possible in terms of the purpose for which tables are used, that is the functions which it will perform for its users. Sections two to five of Chapter 5 are concerned specifically with the derivation of the specification for the software component of the system and with the general problems of the design and the implementation of this component. As pointed out in Section four of Chapter five a specification of the software component must be derived from the functional specification of the system as a whole and it is therefore necessary to investigate first how the specification of the system as a whole can be arrived at. As will be seen shortly this process is of cmcial importance for the overall success of the whole undertaking.

11.2

DERIVING THE SPECIFICATION OF THE SYSTEM AS A WHOLE

11.2.1 A Procedure for the Derivation of the Specification The history of real time systems is very much a tale of toil, sweat and disappointments. At best these real time systems usually come into operation, after varying delays. At worst, they have to be dismantled and removed. Sometimes, indeed, they are not even put together. The usual excuse is to present these troubles as the inevitable penalty of poineering. Admittedly, ten years ago we did not employ computers to control aircraft, nor to control all the systems within an aircraft. However, a study of the history of these troubled systems shows that this is merely a convenient excuse. In fact, the tme cause lies not in technology but in management thinking, or, to be more precise, the lack of such thinking. On investigation it is found that most of the problems had already been built into the project well before any engineering even started. In this section we shall therefore describe a four step procedure for deriving the specification of the system as a whole. Such a specification makes it possible to decide firstly whether to go ahead with the system, and secondly if the decision is taken to go ahead, to eliminate the main sources of the troubles which bedevilled these projects in the past.

164

The procedure stems directly from the definition of a real time system as a tool to assist in performing a given activity. The activity may be the control of interceptor aircraft or the control of the systems on board an aircraft. Whatever the activity, however, one clearly cannot design a tool to assist in its performance unless one is quite clear about what one is trying to do and how one intends to achieve one's purpose. Therefore, the first step in the sequence is: 11.2.1.1 Analysis of the Activity The fact that a real time system is a tool for performing an activity means that it is essential to be quite clear about the nature of the activity to be performed. To achieve this it is necessary to carry out a formal analysis of this activity. The framework for such an analysis is in three parts: The purpose of the activity: The available means: The constraints. It may be thought that when an activity has been going for a long time all this will be known. This is not necessarily so. To start with, there is the tendency for the activity to become an end in itself. This has been neatly illustrated, with reference to that famous saying about the advantage of producing a better mousetrap, by pointing out that actually the real purpose is not to make a better mousetrap but to kill mice. As regards means and constraints, it is doubtful whether an attempt was ever made to encompass them all, on top of which they change with time. Where the application is a new one, say the control system for a new air to ground weapon, a precise definition of the essential purpose must be formulated. Outstanding design breakthroughs have sometimes been due to a clear realisation of the essential purpose. Where applicable, quantification of the purpose is of the utmost importance. Thus for instance, in the above case of an air to ground weapon, the degree of precision of the guidance system which is required may have a decisive impact on the means available for implementation. Having determined precisely the purpose, it then becomes necessary to consider the means available to achieve it. Thus, for instance, in considering a system for the control of an air-to-ground weapon, it has to be borne in mind that the purpose may be achieved either by utilising the pilot in the aircraft or it may be possible to utilise ground based resources operating from a knowledge of the position and parameters of the flight of the aircraft relative to the position of the target. Whichever way one performs an activity there are always constraints on what may or may not be done. In the case of the air-borne weapon with a control system operated by the pilot of the aircraft, there are a number of constraints due to the fact that the system is air-bome in an aircraft and a further set of constraints due to the fact that the human operator also has a number of other tasks to perform. The analysis of the activity must be fully recorded as a formal report. This will help to ensure that it has been thoroughly done since thoughts scribbled on backs of envelopes are usually only half-baked. This formal report then serves as the input to the next step of our procedure. 11.2.1.2 Operational Requirement On the basis of the analysis of the activity it becomes possible to define a tool or tools which will assist in its performance. There may be a number of possible tools depending on which of various possible methods may be employed as well as tools suitable for various phases or aspects of the activity. Each tool demands a separate definition, which must again be a formal document. This document lists the capabilities required for the tool to be useful as a tool. It is therefore usually known as the operational requirement. In preparing the operational requirement it is not enough to list the functions which the tool has to be capable of performing. Where the tool is intended to be used by a human operator, as is mostly the case, both the operator and his tool will have functions to perform. The operator has two groups of functions to perform, one is the group of functions which are complementary to those of the tool and which have to be performed by the human operator at the same time in order to achieve the required results. The other group are the functions which the operator has to perform in accepting information from the system and in order to control the operation of the system. These are additional tasks for the operator, due to the introduction of the new system and unless these are more than compensated for by the easing of his previous tasks, the use of a real time system may not be worthwhile, and indeed if the total tasks demanded from the operators exceeds their capabilities, the use of the new system will not be possible. There is in fact a case on record of a real time system for the control of aircraft which could not be put into use because the total tasks imposed on the operators exceeded their capabilities. The problem of allocation of functions between man and machine is treated in Chapter 9. It lists the main points that should be considered as:

165

(a) crew work load (b) new skill (c) communication among new positions (d) hand-off of functions from one position to another (e) possible crew contribution to availability through primary and secondary crew functions allocations. Methods for determining the optimum man-machine allocation of tasks are described in the references given in that chapter, as are examples of how the problem was solved in some systems, such as the space shuttle orbiter. The last section of Chapter nine surveys briefly some of the equipment for the implementation of the man-machine interface. Having determined the work load it now becomes possible to quantify the maximum load which may be imposed on the operator by the need to control the system, or in other words, the limit of the load which may be imposed on the operator by the man-machine interface. This limit will be a crucial part of the specification of the system. Following this all the other functions of the tool have to be fully quantified. This being a real time system the first and major consideration is that of response time. The limits on response time may have to be quoted on a statistical basis, that is as maximum acceptable response times for various percentages of cases. With some systems there will be an absolute overall limit which must not be exceeded under any circumstance and this raises problems of system integrity which will be discussed in 11.2.1.3. Response times are not the only things which have to be quantified. A limit has also to be computed for the maximum percentage of erroneous results which will be accepted. Again these results may depend on the type of erroneous results. There may be instances where a certain percentage of cormpt messages may be acceptable but with a different limit on instances of complete loss of a message. This latter limit may possibly be nil. Even the most effective tool will avail but naught unless it is used effectively. The operational requirement must therefore include six exhaustive forecasts about the future use of the tool, namely: (a) How it will be used - this really boils down to the consideration as to how the system will be integrated with the higher level system of which it forms a sub-system. Problems which have to be considered and provided for are such points as the impact on the organisation, changes which may have to be introduced in the organisation, physical arrangements for the system such as the provision of suitable space, the provision of suitable operators and so on and so on. (b) Preparations to be made for the use of the new tool following directly from (a) this requires the planning of such activities as the education of people in the organisation to accept the new system, training operators for it, arranging for the provision of all the physical requirements, etc., etc. (c) How it will be introduced into service again following from (a) above; plans have to be laid for the introduction of the system into service. It may be that the system is a tool for an on-going activity which must not be interrupted while the system is being introduced into service. A way must, therefore, be prepared of achieving this. Alternatively, it may be a tool for a new activity, in which case preparations must be made for its integration with whatever it will have an impact on. Thus, for example, if an air traffic control system is introduced into an area where no such activity was previously being performed, arrangements have to be made for this new activity to be accepted by the pilots of the aircraft. (d) How it will be tested for acceptance when the system is delivered it becomes necessary to determine within a comparatively short period, whether the system does, in fact, perform to the specification to which it has been supplied. Since it is by no means easy in the case of more complex systems to test all the functions of the system under all the conceivable circumstances which may arise, plans must be carefully worked out well in advance to achieve the most comprehensive testing which is possible within an acceptable period of time and which will still prove adequate to determine whether the new system should be accepted as meeting the specification. (e) How its performance will be monitored many a system has caused utterly unexpected side effects. It is, therefore, essential to monitor the actual performance of the system in use in order to determine how it compares with the envisaged performance both as regards benefits and the expected costs. This again is something which may not be easy to do unless the facilities for doing this have been provided in advance both in the design of the system and in the plans for using it. (0 How it will be maintained on this point it is necessary to find out in advance what facilities it may be practicable to provide for the maintenance of the system since the level of such facilities has a direct impact on the way the system will have to be designed. The extreme case in this respect is that of space-bome systems whether the maintenance facilities are simply nil.

166

The success of the whole approach clearly depends on the thoroughness with which the work is done. Indeed, unless the operational requirement is very carefully worked out, trouble will arise very quickly, for there will be repeated modifications to the operational requirement. If these go on for long enough the project will tend to go on forever. Such a project may sometimes get into the press and thus give some computer experts an opportunity to publish articles on the technical reason for the long delay each expert with his own pet reason and all of them equally irrelevant to the real problems. 11.2.1.3 Procurement Specification From the definition of the tool, the procurement specification can be prepared. It is vital that the procurement specification should be both complete and purely functional: that is, it must specify completely all the functions which the system should provide, but not lay down how the system will be designed internally to achieve this. In a nutshell, a procurement specification must be all about what and nothing about how. In practice, procurement specifications tend to go in the opposite direction. It happens like this: an organisation which is about to embark on a real time system feels that it would be safer to have some computer engineers of its own. These engineers are then given the task of preparing the specification. To this end they will extract a certain amount of information from managers and operators after which they proceed to do precisely what engineers are supposed to do, that is they go off to work away on how the system may be engineered. With any luck the result will be a procurement specification which starts out with a couple of paragraphs on what the system is supposed to do and then goes on to consider at length how such a system may be engineered a most enjoyable exercise for the authors, the more so, as they know that it is not they who will have to implement it. The correct format for a Procurement Specification is in four parts. (1) Functional Requirements. For each function which the system is to perform, a precise definition of the function has to be given. Also for each function, the response time has to be specified in the manner described in 11.2.1.2. Careful consideration should be given to the question of whether there is an absolute limit on the response time under all circumstances and if so whether this limit is of the order of a few tens of seconds or whether it exceeds two minutes. The reason for this is that while it is possible at the present state of the art to guarantee a response time as low as fifteen seconds for one or more functions under any circumstances, this is possible only through the use of special equipment and special design techniques. Such equipment and techniques are rather expensive so that there is likely to be a very significant jump in the cost if the absolute limit of the response time, even if this applies to only one function, is less than approximately two minutes. In addition to the response time it is also necessary to specify the freshness of the data. Consider, for example, an air defence system which has a response time of thirty seconds. This will then present requested data within that period. There will, however, be an additional requirement that data so presented must represent the situation as it existed in the outside world no more than say sixty seconds prior to the presentation. This is usually referred to as the freshness of the data. For each function one also has to specify the resolution and accuracy required, on a statistical basis. Where a function has to be performed in conjunction with existing interfaces, whether human or otherwise and where equipment to be interfaced with is either existing equipment which is not part of the specification or else where the interface has to comply with given restrictions as in the case of standard interfaces, the interface characteristics have to be adequately specified. One of these characteristics of the interface is the load which may be imposed on it. As has been seen, this is applicable whether the interface is human or otherwise. (2) Available Inputs As the system will have to produce the output information from the data which will be available to it, it is clearly necessary to provide the would be designers with full information on such data. The format for this information is similar to that of the required outputs. For each data source it is necessary to define the information provided by it, the format, average rate and peak rate, number of interface calls per second, accuracy and resolution, availability and integrity and the full characteristics of the interface across which it is provided. It may also be necessary to give the freshness of the data, that is the time interval between the moment at which the data is offered at the interface and the moment at which it was a valid description of the outside world. (3) Overall System Constraint Requirements The six forecasts (a) to (0 in 11.2.1.2 have to be carefully analysed to see what implications they have on the system. Such implications may well include physical constraints such as maximum weight or size. From the forecast of how the system will be used can be deduced the time at which the system will be required, and also such requirements as facilities for training operators to be provided by the potential supplier in advance of system delivery, and similarly, facilities for training maintenance operatives. From the three forecasts it may also be possible to specify the provisions which the supplier will have to make for conducting

167

the acceptance tests and for monitoring the subsequent performance of the system. From forecast (0 it is possible to specify the limitations on the maintenance facilities. An extreme case occurs in the case of spaceborne systems where maintenance facilities are nil. There is yet another consideration which is well worth adding to the specification, namely margins on the capacity of the system. All the quantitative aspects of the forecast use of the system are of necessity estimates with margins of uncertainty in them. It is therefore a necessary precaution to specify the spare capacity, both in load and storage, which the proposed system should have. 50% space capacity is usually regarded as the minimum at the specification stage and in many cases it may be desirable to go beyond this minimum. Alternatively, it may be possible to specify a somewhat lower figure, say 30% to 40%, provided the capacity can be increased at a later stage, when required. In this case a quotation should be requested for such an extension and if this is necessary, proof that this may be done without interference with the operation of the system. (4) Performance Guarantees From the cost benefit analysis described below in section 11.2.1.4 it is possible to estimate the damage which the potential user will suffer if the system does not perform as specified and on this basis, specify the guarantees demanded from the potential supplier that he will meet the specification both with regard to time scale and performance. It may prove very difficult in practice to find a supplier who will be in a position to provide adequate guarantees. The cost benefit analysis may also show that the damage can be reduced if advance notice of pending delays or envisaged difficulties in meeting the performance specification became available. This may make it possible to specify reduced penalties if advance warning of non-performance is given. It will be seen that nowhere in the specification is there any mention of reliability. The reason for this is that reliability is not a functional characteristic of the system and therefore, need not be specified. Reliability effects such functional features as response time and integrity and also maintenance requirements. As these are really the aspects which are of interest to the future user, it is these that are fully specified and how they are to be achieved is left to the supplier. 11.2.1.4 Cost-Benefit Analysis On the basis of the work done in steps 1 and 2 the potential user must now quantify the benefits expected from the proposed system. This is by no means always an easy task. It must nevertheless be done, as without it a rational decision is clearly impossible. In due course, tenders will arrive in response to the procurement specification. These typically contain a great deal of glossy material about how marvellous is the computer used in the system, how it has sixteen bits or whatnots to each word and much else which is not of real interest to the potential customer. Somewhere in the proposal it may even state how the system measures up against the requirements and what guarantees the supplier is prepared to offer that the system will be delivered on time and perform as specified. From those proposals which provide this information, the potential user then obtains the cost of acquiring the system. The tenders will also, if they provide the information which they should, make it possible to prepare firm estimates of the cost of the six activities (a) to (0 forecast in the operational requirements. It is the cost of these six activities together with the purchase cost which is the total cost of using the new tool, and the cheapest tender, incidentally, is the one giving the lowest total cost. Knowing now the cost benefits and the total cost of the system it becomes possible to determine its profitability. The result of this may well be an iteration or iterations of steps 1 to 4 of the sequence in order to consider alternative approaches and means of automation. These iterations may even lead to a conclusion that a real time system would not be worthwhile. Only if a particular real time system does definitely emerge as worthwhile should a decision to go ahead be taken. Some organisations prefer to do their own system design and some projects have indeed been successfully done in this way. A procedure like the one outlined above is nevertheless still essential. It is clearly not an easy task to carry out thoroughly the investigations required in the four steps of our procedure, the more so as this work is almost pure thinking which is hard labour indeed. Not suprisingly, there is a marked reluctance to adapt this procedure. The excuse most often advanced is that the time scale of the project does not allow for this work to be done. Yet, the people who advance this excuse often know full well that any aspect which is skipped and does not come right by sheer good luck will take very much longer to rectify at a later stage and will cost many more times to do so.

168 11.3 SYSTEM DESIGN

11.3.1 Overall System Design We move on now to the problem of designing the optimum system to meet the specification. Chapters 5 to 9 are directly concerned with this task. The first phase is that of establishing the broad outline of the design. The approach to this is basically the same as that adopted for the problem of deriving the specification, namely to consider the means available for achieving the purpose while observing the constraints. The purpose is to meet the specification, which is now clearly defined. One part of the design does in fact, follow directly from this specification. These are the output interfaces. It is known from the specification, or it is possible to deduce directly from it, what information will have to be provided. The constraints on the interfaces over which this information will have to come are also given. A survey must, therefore, be carried out of all relevant available output techniques and equipments to determine the best interfaces to use. The next step is to determine firstly whether the required information can in fact be obtained from the available input information. Assuming that this is so the next step is to choose the interfaces which may be capable of capturing the input data within the constraints given in the specification. This is done in the manner similar to that used on the output interfaces. Having made a first choice of the input and output interfaces it now becomes necessary to produce a first estimate of the total processing task and of the storage which may be required to carry it out. For this first iteration of estimating the total task it suffices to divide it into two main components, input/ output load and processing load. With regard to the first of these a table has to be compiled which gives the following three parameters for each input and output: average rate, peak load and response time. That of Chapter 5 is more detailed than is required at this stage, of the design work. The benchmark method mentioned in Chapter 6 is quite adequate and the easiest thing to do is to assume any computer of which experience exists within the design organisation so as to produce this first estimate quickly. From the loading figures and from a consideration of the integrity requirements given in the specification it may be possible to determine whether the system can be a straight forward single processor design or whether a more sophisticated system is required. If the integrity requirements are such that the maximum break acceptable, even for only one of the functions, is of the order of a few tens of seconds then a very special system design will have to be adopted. The several approaches which are available to achieve this are surveyed briefly in Chapter 6. All of these are based on the use of redundant equipment, automatic fault detection and automatic procedures to overcome the effects of the detected fault, except that the majority voting method provides fault detection and recovery from the fault combined. The approaches which involve the use of redundant modules are those for which most experience is available so far. In these automatic recovery systems the supervisor level software has to be specially developed for both the specific hardware used and the particular application. Where the integrity requirements are of the order of a couple of minutes or so, dual processor systems with manual intervention in the case of failure will suffice. It is then possible to manage without the use of specially designed hardware. Also there is by now a fair amount of experience available for such systems in a variety of applications. Where the integrity requirements permit a break of the order of the time required to repair a computer i.e. about a couple of hours, a single processor configuration may be adequate to provide the required level of integrity. In applications where this level of integrity is adequate and where a single computer can provide the required capacity a straight forward single computer system can therefore be used. In these cases the design can then be completed using the design procedure described in Chapter 4. Situations sometimes arise when a single computer capable of performing the required tasks on its own is available, but there may be objections to its use. For instance, it may not meet the constraints regarding size or the environmental specification or it may be very much more expensive than somewhat slower computers. In such a case, or where a powerful enough computer is not available, alternative approaches must be considered. These are of three types: firstly, there are designs which employ various methods of reducing the computer load so as to enable the system to get by with a single computer; secondly multi-computer designs; thirdly multi-processor designs. These will be discussed in the following three sections. 11.3.2 Interfacing to the Computer A fundamental concept in data acquisition by a real time computer system is that of survival time. Peripherals like those cited in Chapter 3 deliver data at a certain rate s In most cases such as those of drums or disks, this rate is regular. In other cases such as that of the keyboard cited in that Chapter, the rate is irregular. In both cases, however, the situation is that an item of input data is made available to the system for a certain period and then superseded by a new item from the same source. The previous item may be lost in the process. The time for which a particular item of data is available for acquisition by the system is known as the survival time of that item of data. There is an analogous situation in data output. Once, for instance, a drum or a magnetic tape transport signals a demand for a word a limited period of time is available within which this word is to be delivered if it is to be recorded in its proper position. It is thus seen that a requirement for a given response time applies not only to requests made by human operators but also to demands made by output equipment. It is essential for

169

the successful operation of a real time system that input data offered to the system is not lost and that data demanded is delivered within the appropriate response time. It is the task of the control of the input/output operation to ensure that this is achieved. Section 3.5 lists five methods, designated (a) to (e), of communication between the computer complex and input/output devices. Methods (a) and (b) were quite common in the early days of computers but are no longer used because of the computer time wastage which they caused. Method (c) is commonly known as polling, while method (d) is often referred to as program interrupt. Both of these methods involve a time penalty, often referred to as an overhead in that in both methods the computer has to switch from whatever problem it is doing at the time to a special, so called, interrupt program which either accepts the input data or delivers the relevant output data. This overhead is then repeated when the computer returns to the interrupt program having completed the input or output process. This overhead in real time computers is typically between 10 and 50 microseconds in each direction. The difference between the polling and the program interrupt method is that in the case of the latter the jump to the interrupt program occurs only when a device signals that it has data for or requires data from the computer, whereas with the polling method, the switch to the interrupt program occurs at a signal given by a real time clock and the computer then enquires from the input/output device whether it either needs data from or has data for the computer. Clearly such enquiries have to be made at intervals smaller than the survival time. The polling method could, therefore, be wasteful in that on a great number of enquiries it may be found that there is no data available or no data is required. However, this waste may be more than compensated for in the case where there is a large number of possibly similar input and output devices which can be interrogated once the computer has switched to the interrupt program. Clearly, if at the expense of a single overhead on jumping to the interrupt program the computer succeeds in servicing a number of input/output devices, this will be more efficient than having to suffer an overhead in each individual device as in the case of the program interrupt method. The choice between the polling method and the program interrupt method, therefore, depends simply on which would be more efficient in a particular case based on the number of devices, and degree of similarity between them and on the relative frequencies at which they require attention. In some systems both methods are in fact used: the polling method for a group of similar devices, in particular data communication devices; while the program interrupt method is used for other devices. The most efficient method of communicating between input/output devices and the computer complex is the direct memory access (DMA) because in this case there is no overhead. At most, the data processing will be held up because the computer is prevented from gaining access to its own store, while the input/output is taking place. The computer will not be held up if it so happens that at that particular moment in time it does not require access to the store which, for instance, may well be the case during the latter part of, say, a multiplication instmction. There are also certain ways of designing a system in a manner which will enable direct memory access to go on in parallel with processing as will be seen below. The DMA method does, however, incur a hardware penalty in that it requires an additional unit sometimes known as a DMA interface unit. This unit is also called various other names such as a selector channel. This method of input/output was developed primarily for such peripheral devices as dmms, disks, and tapes and hence, as pointed out in Section 3.5, for a transfer of blocks containing a large number of words. The rate at which these words arrive or have to be delivered is determined by the device, and if an incoming word, say, is not required when it is presented and before the next word from the same source arrives, it may be lost. It is in order to ensure the capture of data within the survival time that a DMA interface has not only the capability of access to the store but also a modicum of arithmetical capability and a couple of store registers. The transfer of a block of data is initiated by software which loads one of the registers in the DMA interface with the starting address in the store of the block to be transferred within the store, or the first address of the store zone which is allocated to a block which is expected to come in. The other register is loaded with last address in the store or in other designs with the number of words in the block. The first word of the block on, say, input, is stored in the starting address and the DMA interface increases this address by one for every word so that incoming words go into successive locations. It also compares the number of words with the word count, or else compares each successive address with the last one so as to determine when the transfer of the block has been completed. When the end of a block is detected a program interrupt is generated. There are thus two overheads for each block: the setting up of the block transfer and the interrupt generated on its completion. In some modern real time systems, this method of input/output is also used for devices which transfer words at a high but not necessarily fixed rate and not necessarily in blocks. In this case the DMA interface unit supplied by the manufacturer may not be suitable and the system designer has to design a unit of his own. One further concept of importance in interfacing input/output equipment to computers is that of buffering. On the input side, these are devices which will accumulate data so as to minimise the interrupt loading on the computer. As an example, consider a fast data transmission link which delivers a bit at a time. The buffer will.in this case, accumulate 16 bits in the case of a 16 bit word machine and then interrupt directly to memory to insert the word it has accumulated. For output, such a buffer will operate to break up a block of data into a stream of single bits.

170

With the extension of real time systems, much of the input data has to be captured at remote locations and similarly output data may have to be supplied to remote locations, so that data transmission is playing an increasing role in computer real-time systems. Many methods of data transmission have been developed with speed ranging from 75 bits per second up to 2 million bits per second. By its very nature, data transmission requires international standards, and there is now quite a large number of such standards in the various methods used. These are surveyed in Section 3.6. All data transmission devices are prone to errors. The detection of these errors, leading to requests for retransmission or the correction of errors by the use of error correcting codes may be accomplished by software inside the computer or by hardware outside it. Because of the specialised nature of the operations which have to be performed for error detection and correction, the latter method is probably more efficient, and this is also surveyed briefly in Section 3.6. 11.3.3 Design of the Data Processing Task 11.3.3.1 General Having chosen the input/output equipment one now has to proceed to the design of the computer complex and of the tasks which have to be performed by it. The three basic tasks which the computer complex has to perform are: (a) (c) input/output maintenance of a data base. (b) data processing

A presentation similar to that of the Phillips diagrams in Chapter 5 of these tasks is shown in Figure 11.1. Another presentation of these tasks is that of Figure 7.1 of Chapter 7. For the design of the computer complex and its tasks, it is necessary as a first step to determine the magnitude of the task. Section 4 of Chapter 3 describes a method of estimating the processing load and this method is summarised visually in Figure 7.2. However, it is necessary to estimate also the input and output tasks which will have to be performed by the computer complex. The relationship between the input/output task and the data processing task is illustrated in Figure 11.2 which is also a presentation of the 4 levels of operations of a modem computer. The level of operation with the highest priority is that of the direct memory access described in the preceding Section. The reason for this is that the computer is so designed that this takes precedence over anything else the computer may be doing. The next level of priority is that of program interrupt, again described in the preceding section. The input and output by the polling method is also done at this level since the polling is normally achieved by entering an interrupt program as a result of an interruption from a real time clock. Actual data processing is done at the third level, while a further, lowest priority level is used for self-diagnostic problems when there is nothing of a higher level to be done. In a real time computer of straightforward architecture like that of most mini computers, the bulk of the operation at the direct memory access level and all of the work at the program interrupt level comes out of the total time available and it is, therefore, necessary to estimate the total load represented by all three tasks. It is also necessary to estimate the amount of memory which will be required to contain both the data bank and the program required for the tasks. 11.3.3.2 Design of Simple Systems. A very thorough method of preparing these estimates is described in Section 4 of Chapter 7 and is summarised in Figure 7.1. The first step is to break down the three tasks into successively more detailed levels. The Phillips diagrams for presenting processes described in Chapter 5 are very suitable for this purpose, their big advantage being that the same method of presentation applies to all the successive levels. Having achieved a detailed enough level it then becomes possible to actually estimate the numbers and types of instructions which will be required to execute the various detailed processes. To do so in a machine independent manner, Chapter 7 introduces a new high level language based on the so called Reverse Polish Notation. It is pointed out that other higher languages could also be used for this purpose. In practice estimates are often prepared without actually going through the process of translating the model into sequences of elementary operations. If programmers are available with previous experience of programming similar tasks, they are very often in a position to give a first estimate of both the number and the type of elementary operations which will be required to carry out these tasks. Such estimates will inevitably be based on experience gained with a particular computer and are thus not machine independent. This problem can be overcome by means of the bench mark method described in Chapter 5, as will be explained later. Let us continue, however, with the review of the method presented in Section 3.4 of Chapter 7. Once the tasks to be performed have been detailed to the level of elementary operations which effectively means that the tasks have been programmed in detail (or to use the expression of Chapter 7 the model has been translated into sections of elementary operations,) it becomes possible to determine the following load parameters.

171

Fig. 11.1

Computer complex tasks

CMRECT MEMORY ACCESS LEVEL

PROGRAM INTERRUPT LEVEL

ACTUAL PROCESSING LEVEL

SELF-DIAGNOSTIC LEVEL Fig.l 1.2 The four levels of operation

172 (1) Distribution of Operations This gives the relative frequencies of the various types of elementary operations and makes it possible to choose the computer with the most suitable order code. (2) The times to perform the various tasks are given in parametric form, the parameters being the store cycle time and the central processor's operation time for elementary operations. The total time for the tasks include the overheads due to program interrupt and the store cycle times required for DMA operations. (3) The amount of storage required for data This is given as a histogram by the length of the item of data as shown in Figure 7.4.6.1 and makes it possible to choose a computer with the optimum word length for the data involved in the task. (4) Amount of memory storage required for programming This is a number of instructions plus a 50% allowance for the fact that some instmctions may occupy more than one word length. This 50% allowance is appropriate for machines with a short word length, e.g. 16 bits. In the case of machines with a word length of 32 bits, this allowance is not really necessary since virtually all instructions do fit into the single word. These 4 load parameters are clearly required to make the right choice of the most suitable computer. Since, however, we are dealing with a real time system there is a further requirement, namelv, that the response time should meet the specification and this means that one has got to go through the individual chains of operations required to produce each response and see that the time required to generate the response is within the specification as illustrated in Section 3.4.8 of Chapter 7. It should, however, be realised that the method described in Section 3.4. contains a number of major simplifications. For instance, the overheads given in Section 3.4.7 assume that only two registers have to be saved and restored. In fact, the number of working registers varies from 2 to 16 and if registers are automatically saved and restored, all of them, rather than just two, are operated on. In machines with a large number of working registers, automatic saving and restoring of registers has to be done by software and takes much longer than one store cycle per register in each direction. Also when computing the response time allowance has to be made for the time which will be taken out by interrupts both at the DMA and the interrupt level for input and output operations for other tasks. There may also be interaction with other tasks on the actual processing level. It may also be noted that while the histogram of the length of the various items of data should make it possible to choose a machine with the optimum word length, the choice of word length in computers which are actually available is rather limited as most of them have word lengths of either 16 or 32 bits, with only a few computers with word lengths of 8, 12 or 24 bits. There is also the problem of priority levels for interrupts and interrupt programs. The priority levels for interrupts are decided on the basis of the survival time of the data. Since the purpose of input/output operations is to ensure that all data presented to the system is captured and all data delivered within the survival time, priority levels have to be so arranged that all the actions required to, say, capture a given item of data have to be performed within the survival time of data at lower levels. Otherwise, input data may be lost. This has led to the concept of differing priority levels for the interrupt programs which capture data. Some computers do, in fact, provide now a facility for maintaining a record of the priority level of a given interrupt program. With this facility, an interrupt program will not in turn be intermpted by another intermpt of the same or of a lower level. There is a case on record of a system which has been programmed on two computers, one with this facility and another one without it. In this particular case the load on the computer without this facility turned out to be 20% higher than on the computer with the facility. This was probably an extreme case (there were 1100 program interrupts per second.) But it, nevertheless, shows that it is well work checking the various facilities for dealing with program interrupts provided on the various computers considered. 11.3.3.3 Design of More Complex Systems Chapter 7 provided a useful example of a simple system and an explanation of how such systems are designed. Chapter 5 deals with the design problems of more complex systems. It starts off by pointing out that the design process may necessitate compromises in the operational requirements. As has been seen in Section 2 of this summary, what is possible may indeed lead to modifications in the specification. However, it is essential that all such modifications are made before design begins. We, therefore, assume now that the specification has been settled and consider the problems of arriving at the optimum configuration of hardware and software components which will meet the specification. There are a number of considerations which are of special importance in the design of avionics systems. One of these is system integrity, since avionics systems often replace a number of separate devices for doing different tasks and the safety of mission and crew often depends on the continued availability and integrity of the system.

173 Standardisation is another major consideration in avionics systems, partly for the same reason as it is required in data communications. The business of flying is an international one and in these days of alliances like NATO this is true not only of civil aviation. In discussing the various possible system configurations Chapter 6 employs the PMS Notation proposed by Bell and Newell. Potentially, such a notation can be very useful because in the computer field there is the problem not just of technical jargon but of a babel of jargons, the various experts each having their own. Whether the potential of the PMS Notation will be realised in practice depends on the extent of its acceptance. However, the very fact of the multiplicity of jargons does not augur well for the chances of its acceptance. It is not only the language which could do with standardisation but also the interfaces between the various units which make up an avionics system. A certain amount of standardisation has resulted from the work of such bodies as ARINC but this has not so far been extensive. Such standardisation would be of great help because of the method of maintenance of avionics systems. There is in this field a great deal of first line maintenance by which is meant the replacement of a faulty unit by another one. These replaceable units are known as line replaceable units. The starting point for the design process is an exhaustive presentation of all the tasks which the system has to perform. Section 3 of Chapter 6 suggests three complementary, implementation independent, representations of the system task together with a complete list of all inputs and outputs as an appropriate form of such a presentation. The next step is to estimate the load which will be generated by all the tasks which the system is to perform. The method for doing this is essentially the same as that described in Chapter 4 and the data on the load and memory requirements that has to be determined is also the same. Some quick methods for first assessment of the load and memory requirements are mentioned in Chapter 6. However, to get a more accurate estimate it is necessary to resort to the use of bench marks. The way this is done is as follows: the tasks to be performed are detailed to a level which enables programmers with experience of programming this type of task to estimate the number of instmctions that will have to be performed and the amount of memory required. These estimates will be related to the particular computer on which these programmers will have gained their experience. These programmers then proceed to identify short programs which are (a) typical of the programs which will have to be written and (b) are those parts which will be the most repetitive ones so that the computer or computers will spend a large part of their time doing these short programs or programs like them. In order to evaluate how well various computers under consideration are suited to the particular system, these bench marks will be sent on to the manufacturers of the computers under consideration for the manufacturers' programmers to code these programs on their respective machines. It is important that the coding of these so called bench marks is done by the manufacturers of the computers since they are the people best qualified to do so. By comparing the bench marks as coded by the manufacturers it is possible to establish performance ratios between these and the computer which was used for estimating the total system load. The next step is to consider which type of system would be appropriate. There are four main types of computer complexes. The first is the straightfoward single computer type of computer described in Chapter 4. Another one is the multi computer complex. An example of this is shown in Figure 11.3. This relates to a simple air traffic control system in which the main computer prepares from the data provided to it as complete a file as possible on all the aircraft in the air space. Each of the display processors analyses the messages given to it by the air traffic controller, determines what information each particular controller requires, extracts this information from the main computer, transforms it into the presentation requested by the controller and displays it. This is a rather simple example of a multi-computer system. Other systems of this type can be very much more complex, containing a great many computers. A third type of computer complex is that which has a single general purpose processor with one or more special purpose processors. These latter are usually input/output processors. They can, however, also be processors which are very fast in one particular task that the system has to perform, e.g. special hardware for performing the fast Fourier transform. The last type of computer complex is the genuine multi-processor in which there are a number of general performance central processors. The last two types of computer complex are only possible when the hardware has been specifically designed for this type of system architecture, since they require so called multiport storage modules and some other hardware facilities. The various methods for interconnecting the components of such systems are discussed in Chapter 6. The choice of type of computer complex is determined not only by the need to achieve the specified response time but also by the availability and integrity requirements. A great deal of development work on high availability systems has been done in the last 15 years or so and there is now considerable field experience with such systems. The current state of the art is that where maximum down times of the order of a few tens of seconds are specified it is necessary to resort to one of the methods classified in Chapter 6 as fault masking methods or stand by redundancy method with automatic reconfiguration. While the fault masking methods hold out great promise most of the actual field experience is with systems using stand by redundancy methods. Where down times of several minutes are acceptable multi-computer systems with manual reconfiguration suffice. A straightforward single computer system like that described in Chapter 7 can only be used if a down time determined by the repair time is acceptable. The repair time in turn depends on such factors as the availability of on site repair facilities or the level of spares holdings.

174

Secondary Radar Inputs

Display Computer

Display Computer

f
/ \

Keyboard /
/

Keyboard \

Rolling Ball

Display Display

Fig. 11.3

Multi-computer system

175 Compiex real time systems require software to control the execution of the various tasks within the system. Such software is often known as the operating system. This term and the type of software denoted by it belong to the domain of large real time systems such as on line systems for scientific computation, e.g. the well known project MAC a the Massachussetts Institute of Technology. The purpose of an operating system is to create a user environment suited to the needs of the user which is almost independant of the hardware. Standard scientific or EDP operating can become very inefficient in real time applications and a case has been described where only 5% of the time was available for actual productive work, the remainder being consumed by the operating system itself. Dedicated real time systems almost invariably have control programs which are specially designed for the particular system. The simplest dedicated real time systems have no control software at all. Individual interrupts are sequenced by whatever hardware priority facilities there are, data is processed as it becomes available and whatever processed information there is, is output on demand. As complexity increases, software has to be added to control the operation of the system. The first step will usually be to introduce a scheduler. This may be required to prevent one task from monopolising the computer to the detriment of the other tasks. With a scheduler, a program on completion no longer calls in another program. Instead each program, as it completes its task, passes control to the scheduler. To prevent one task from monopolising the computer a method known as time slotting is often resorted to. Using a real time clock the scheduler will allocate predetermined time periods to various tasks. In a comparatively simple system the scheduler may control the tasks partly on the basis of interrupt and partly by time slotting. In still more complex systems the scheduler will evolve into a control program which will also pass messages between programs and perform the management of data shared by several programs. The tasks of the control program (or executive as it is sometimes known) will go on increasing with the complexity of the system. Thus, for instance, in a multi processor high availability system the control program will control all input and output, schedule all tasks, manage all the system resources, such as the allocation of working space in the core store to various programs at any one time, and furthermore, because of the special nature of such a system it will also control the system configuration. In this capacity it will exclude from the system any module which is found to be faulty and replace it by a stand-by module. The control program will also, if necessary, recover operation of the system, that is, if for instance, the faulty module was a core store module it will load the replacement module, from the backing store, with the program or data contained in the module which has been replaced. 11.3.3.4 Optimization The right time at which to stirt on the optimisation of the design is when the first complete design of the system is finished, as pointed out in Chapter 4. There is an emotional problem about doing this at that time, since the natural reaction of a designer who has just completed a design is to breathe a sigh of relief and possibly also pat himself on the back for having done a good job. It may help to overcome this emotional problem if it is considered that the first design is of necessity bound to be more a record of the designer's gropings towards a solution rather than an optimum design. Chapter 4 of this book which is devoted to the problems of design optimisation rightly points out that the first step towards optimisation is to become clear on what would be an optimum in the particular case. Clearly such factors as size or cost will have different weightings attached to them in different applications. Furthermore, in the process of determining wh;-.t the optimum would be it is necessary to consider not only the finished product, but also the way in which it will be implemented. On a system of any size, the implementation work will be divided between a number of groups of people. Experience has shown that design and implementation errors are more likely to occur at the seams where the work of the various groups come together. In deciding on the optimum it is, therefore, also necessary to bear in mind the way in which implementation will be partioned so as to minimise the seams and furthermore, to suit the parts of the work to the ability and experience of the groups of people who will be available to do the work. In brief, what may be an optimum design given one set of implementation resources may well not be an optimum design given another set of implementation resources. Also as follows clearly from what has been said earlier on in this summary about the various forecasts of how the system will be used, it is clearly necessary to bear in mind not only the production of the system but also the manner in which it will be used. The advantages of modularity in design and its impact on maintenance and ease of modifiction are well known. What is usually less frequently remembered is that this also applies to the software. Like the hardware the software has to be robust, modular and easy to maintain and modify. There are a number of well known trade-offs in the course of optimisation. One of them is speed versus complexity. Thus for instance a central computer complex which has to carry a very high load may be implemented either by using one very fast computer or a number of slower ones, either in a multi-computer or multi-processor type of configuration. Normally the mle is that the faster computer will give a simpler and therefore better design. A further reason for this is that the price of computers does not go up in proportion with the speed, that is, the through-put per dollar increases the faster the computer. There is, however, with currently available computers a point of discontinuity in this respect. The so called mini computers nowadays offer excellent value for money hardware wise. Where there are no special environmental or availability requirements, these mini computers which are available from a great many suppliers offer outstanding value for money, not only in processing power but also in their input and output facilities. However, their range of speed currently goes up to about a million instmctions per second. Where a higher speed is required, the use of computers designed for large data processing

176 systems will typically increase the cost of the acquisition of the purchasing power by a factor of 10. Therefore, where the processing power required exceeds something like a million instmctions per second, it may be economically advantageous to use more than one mini computer in spite of the extra complexity of a multi-computer or multi-processor complex. Another one of the well known trade-offs is that between hardware and software. Many functions in real time systems, like the error correcting function in data transmission mentioned in Chapter 7 or the fast Fourier transform function mentioned in Chapter 5 are better performed by special hardware than by software. Another application where the trade-off is between software and (usually analogue) hardware is the expansion and off-centering of graphic presentations on CRTs. The worst aspect of the optimisation of the hardware/software trade-off is the dicotomy between hardware and software people in the computer field. The fact that these two groups of designers are in fact different groups with inadequate communication between them, makes it difficult to establish where the optimum trade-off is. Yet another one of these well known trade-offs is that between the choice of proven but less advanced equipment, as against more advanced and perhaps more suitable equipment which is still in the drawing board stage. Apart from pointing out the dangers of relying on equipment which is still on the drawing board it is difficult to give guidance on this trade-off. It is, however, well worth bearing in mind that there are ways of quantifying, to some extent at least, the degree of risk danger in relying on as yet unproven equipment. The three main points to consider in such a case are as follows: (a) The amount of experience of the team designing the new equipment. Here it is important to ascertain the experience of the actual team engaged in the design work rather than that of the organisation in question as a whole. (b) The extent of advance of the new equipment being designed over previous equipment designed by that team. Clearly the greater the jump from the previous model the greater the likdyhood of unforeseen problems. (c) The extent to which the new equipment being designed comes up against the limits of the technology which it employs. Any new equipment which is very close to the limits of the technology it employs will usually require a long development period before it operates satisfactorily. Finally the most important and decisive trade-off of all; simplicity versus anything else. There is no substitute for simplicity and the slogan KISS which is the acronym of "Keep It Simple, Stupid" applies just as much and perhaps even more so to real time systems as to anything else. In searching for the optimum design it would, of course, be nice if some method were available to evaluate the effectiveness of the design before implementation starts. The method available for this purpose is simulation, as described in Chapter 11. There are, however, a great many reservations about this method. The basic problem is that any simulation is only as good as the assumptions on which it is based. There is a case on record of a system which has been simulated at great cost and effort prior to implementation, the simulation having proved among other things that the proposed system had ample processing power, including provision for further expansion for many years ahead. Yet it was discovered that the processing power was totally inadequate even before implementation was completed. One of the reasons it was found was that the load on the system was badly underestimated. Simulation has been found to give misleading results in so many cases and at such great cost that it has been called by some people "a sink for time and money". Simulation may, nevertheless, be useful provided it is borne in mind that it can be extremely dangerous if it is employed as a substitute for thinking or if the cost or effort required to carry it out are underestimated. 11.3.4 A Case History A highly enlightening case history which illustrates the various aspects of system design discussed throughout this book is described in Chapter 8. The example chosen is that of a computer system for the control of aircraft power plant. Section 2 of Chapter 8 highlights the fact that the whole system is conditioned by the environment in which it will operate. The top part of Figure 1 illustrates that the environment is made up of social, economic, technological and regulatory factors. It is in this environment that the market requirements will arise for an economically justifiable tool to perform a given function. The lower part of Figure 1 neatly illustrates the hierarchical nature of the real time systems discussed in this book. The market requirement is for a given mode of transportation which is met by a certain vehicle. The vehicle is in itself made up of three sub-systems: the air frame, the means of propulsion and the flight systems, such as communications and navigation equipment. The system for controlling the power plant is in itself a sub-system of the propulsion sub-system. The point is forcibly made in Section 2 that the real purpose of the design and implementation is not just to obtain the customer's signature on the acceptance chitty. It is the service life of the system which is the real justification for it. Hence, the importance of the various forecasts of use described in Section 11.2.1.2 of this summary for the derivation of the specification. Section 3 of Chapter 8 is concerned with the derivation of the operational requirement. It brings out the fact that the operational requirements must embrace not only the normal operation of the system but also of the

177

failure modes, not only in the system itself but also in the associated systems, including the human factors in its environment. These considerations are continued in Section 4 where the point is brought out that not only must the system continue to operate in a pre-determined manner under all these conditions but that its operation must also be monitored, that is, it is also essential to know at all times how the system does in fact behave. Section 5 then deals with the considerations arising from the data acquisition, communications and data processing aspects, while Section 6 is concerned with the considerations of the man/machine interface. Section 7 then goes on to consider the realisation or implementation of the system. The possibility of giving to the designers not only the specification arrived at, but also the operational requirements is considered. This has the advantage of improving the designer's understanding of the specification and should also improve communications across the interface between the designers and the users. In the case of the control system for an aircraft power plant, there is the further difficulty that the power plant to be controlled is being designed at the same time as the system for controlling it. Simulation and emulation methods to help overcome this difficulty are discussed, so is the flexibility that has to be built into the control system to take care of the modifications which will be made in the power plant during its development. The requirements for the software of the system are then considered, and to those listed earlier in the Chapter on optimisation, is added portability, so that proven modules of software can be carried over into similar systems at minimum cost and risk. 11.4 NOVEL DEVICES AND TECHNIQUES

11.4.1 General The last Chapter of this book surveys current developments in advanced technology applicable to data processing and this last Section of the summary briefly reviews the potential impact of these developments on the design of data processing equipment in an attempt to forecast the type of processing, storage and input/output equipment which will be available to the designer of avionic systems in the near and medium term future. 11.4.2 Central Processors The development which is having and will have the greatest impact in central processor design is that of very high speed read-only memories. The availability of such memories makes it possible to replace the bulk of the assemblage of wired gates and bi-stable devices which control the operation of central processors with suitably programmed ROMs. As an example, in work done for the US Air Force the Burroughs Corporation have developed a very basic framework which can be converted into various central processors or into special purpose processors simply by providing the framework with the appropriate ROM. This ease of providing the control function has already led to the appearance of processors with optional instmctions. Such processors provide a more or less extensive standard instruction repertoire to which the user may add a number of instmctions tailored to his application. Such optional instmctions can greatly increase the processing power in specialised applications. A few computers have also been announced in which the machine language as we now know it no longer exists and is replaced by a suitable higher level language. In fact, in at least one case a choice of high level languages is offered. There is also at least one computer where the common and most used nuclei of the operating system have been built into hardware. There is no doubt that all three of these trends will continue and indeed gather momentum. 11.4.3 Semi-Conductor Memories As pointed out in Section 3 of Chapter 10, semi-conductor memories have already superseded magnetic films and are now the only competitors to core stores. The latter have so far kept up in the race for faster storage at lower cost per bit. However, semi-conductor stores are at the beginning of their development, whereas this is not tme of core stores; the latter are, therefore, likely to fall back in the race. The drawback of semi-conductor stores is their volatility in that their contents are lost with the loss of power. This is overcome by the provision of stand by power arrangements using an accumulator battery. There may, however, by applications where the environmental conditions would exclude such back up giving core stores an advantage. As pointed out in the last Chapter it is not only speed and cost which confer an advantage on semi-conductor memories. They can also provide orthogonal access. This means that they can be so designed that they can be written into and read out of not only by words but also in the orthogonal mode, that is the corresponding bits of all the words may also be written in or read out. This makes possible the design of associative processors as described in the next section. 11.4.4. Associative Processors The name "associative processor" has a historic origin in that computer users have for long been hankering for the ability to address data by the content of such data rather than by means of an index of where the required data was located. This is analogous to being able to stand up at a conference, say, and request Mr Brown to contact Reception instead of having to look up an index, if one exists, to find out where Mr Brown is sitting. To appreciate the full power of this type of processing, however, it should be realised that not only

178

access, but also arithmetic and logic operations can be performed on many items of data simultaneously. The combined effect of the low cost and orthogonal property of semi-conductors together with the LSI cost-effectiveness in arithmetic and logic is to make it feasible to produce an array of up to several hundred arithmetic and logic units each with up to thousands of bits of storage, all controlled by a common control unit. It is thus possible to execute an instruction on a great many items of data simultaneously. This is now known as the SIMD (for Single Instruction, Multi Data) mode of operation. So far the cost of such SIMD processors is very much higher than the cost of the mass produced mini computers. With the ingenious methods which have been developed over the years to overcome the lack of multiple data operation, there have not so far been many applications which would justify the use of SIMD mode computers. However, design and cost effectiveness studies on the use of such computers in air traffic control are now going on in the United States. It is probably safe to say that the combined fact of the Parkinsonian Law that applications expand to fill the available means and of the reduction in the cost of SIMD computers will result in their progressive introduction into use. 11.4.5 Mass Memory All mass memories available so far are electro-mechanical ones with all the attendant problems. This presents a particular problem in avionic systems since there is not even now available a fully mgged disc. Magnetic bubble memories may well, therefore, find their first application in avionic systems where their low power consumption would be an additional advantage. 11.4.6 Displays As mentioned in Section 6 of Chapter 9, CRT displays are used in real time systems for the presentation of both graphic information and of messages made up of characters. Displays using light emitting diodes afford a replacement only for the latter application. Graphic presentation will become possible with plasma panels. This is another current development in display technology and consists of a panel containing a large number Of small cells filled with ionised gas. Each of the cells can be switched on or off by a suitable addressing mechanism and will emit light when switched on. The main economic impetus for the development of these panels is the possibility of their replacing the tubes in television sets. However, both light emitting diodes and plasma panels are candidates for early use in real time systems because CRTs are bulky, have to be carefully, and hence expensively, mounted for a mgged environment and in addition, have a low average life time.

REPORT DOCUMENTATION PAGE 1. Recipient's Reference 2.Originator's Reference AGARD-AG-183 5. Originator 3. Further Reference 4. Security Classification of Document UNCLASSIFIED

Advisory Group for Aerospace Research and Development North Atlantic Treaty Organization 7 rue Ancelle, 92200 Neuilly sur Seine, France Principles of Avionics Computer Systems

6. Title

7. Presented at

8. Author! s) Various 10. Author's Address Various 12. Distribution Statement Editor J.N.Bloom

9. Date

December 1974
11.Pages

186

This document is distributed in accordance with AGARD policies and regulations, which are outlined on the Outside Back Covers of all AGARD publications.
14.UDC

13. Key words/Descriptors Airborne computers Digital computers Avionics

Data acquisition Design

681.32:629.73.05

15. Abstract An introduction to fundamentals of digital computers, data acquisition and communication, logical partitioning and optimization of sub-systems is given. A methodology of design is developed by philosophical discussion, detailed description of processes, and by practical examples of the application of basic principles to the problems of system and component design. The technique of specifying a requirement is discussed in detail as are the various steps required to satisfy it. The book provides a helpful background to the non-expert for the acquisition of complex avionic computer-based systems. Where practicable, an extensive bibliography for further reading is provided. This AGARDograph has been prepared at the request of the Avionics Panel of AGARD.

AGARDograph No. 183 Advisory Group for Aerospace Research and Development, NATO PRINCIPLES OF AVIONICS COMPUTER SYSTEMS Edited by J.N.Bloom Published December 1974 186 pages An introduction to fundamentals of digital computers, data acquisition and communication, logical partitioning and optimization of sub-systems is given. A methodology of design is developed by philosophical discussion, detailed description of processes, and by practical examples of the application of basic principles to the problems of system and component design. P.T.O. AGARDograph No. 183 Advisory Group for Aerospace Research and Development, NATO PRINCIPLES OF AVIONICS COMPUTER SYSTEMS Edited by J.N.Bloom Published December 1974 186 pages An introduction to fundamentals of digital computers, data acquisition and communication, logical partitioning and optimization of sub-systems is given. A methodology of design is developed by philosophical discussion, detailed description of processes, and by practical examples of the application of basic principles to the problems of system and component design. P.T.O.

AGARD-AG-183 681.32:629.73.05 Airborne computers Digital computers Avionics Data acquisition Design

AGARDograph No. 183 Advisory Group for Aerospace Research and Development, NATO PRINCIPLES OF AVIONICS COMPUTER SYSTEMS Edited by J.N.Bloom Published December 1974 186 pages An introduction to fundamentals of digital computers, data acquisition and communication, logical partitioning and optimization of sub-systems is given. A methodology of design is developed by philosophical discussion, detailed description of processes, and by practical examples of the application of basic principles to the problems of system and component design. P.T.O.

AGARD-AG-183 681.32:629.73.05 Airborne computers Digital computers Avionics Data acquisition Design

AGARD-AG-183 681.32:629.73.05 Airborne computers Digital computers Avionics Data acquisition Design

AGARDograph No. 183 Advisory Group for Aerospace Research and Development, NATO PRINCIPLES OF AVIONICS COMPUTER SYSTEMS Edited by J.N.Bloom Published December 1974 186 pages An introduction of fundamentals of digital computers, data acquisition and communication, logical partitioning and optimization of sub-systems is given. A methodology of design is developed by philosophical discussion, detailed description of processes, and by practical examples of the application of basic principles to the problems of system and component design. P.T.O.

AGARD-AG-183 681.32.629.73.05 Airborne computers Digital computers Avionics Data acquisition Design

The technique of specifying a requirement is discussed in detail as are the various steps The technique of specifying a requirement is discussed in detail as are the various steps required to satisfy it. required to satisfy it. The book provides a helpful background to the non-expert for the acquisition of complex avionic computer-based systems. Where practicable, an extensive bibliography for further reading is provided. The book provides a helpful background to the non-expert for the acquisition of complex avionic computer-based systems. Where practicable, an extensive bibliography for further reading is provided.

This AG ARDograph has been prepared at the request of the Avionics Panel of AGARD. This AGARDograph has been prepared at the request of the Avionics Panel of AGARD.

The technique of specifying a requirement is discussed in detail as are the various steps The technique of spedfying a requirement is discussed in detail as are the various steps required to satisfy it. required to satisfy it. The book provides a helpful background to the non-expert for the acquisition of complex avionic computer-based systems. Where practicable, an extensive bibliography for further reading is provided. This AGARDograph has been prepared at the request of the Avionics Panel of AGARD. The book provides a helpful background to the non-expert for the acquisition of complex avionic computer-based systems. Where practicable, an extensive bibliography for further reading is provided. This AGARDograph has been prepared at the request of the Avionics Panel of AGARD,

DISTRIBUTION OF UNCLASSIFIED AGARD PUBLICATIONS NOTE: Initial distributions of AGARD unclassified publications are made to NATO Member Nations through the following National Distribution Centres. Further copies are sometimes available from these Centres, but if not may be purchased in Microfiche or photocopy form from the Purchase Agencies listed below. THE UNITED STATES NATIONAL DISTRIBUTION CENTRE (NASA) DOES NOT HOLD STOCKS OF AGARD PUBLICATIONS, AND APPLICATIONS FOR FURTHER COPIES SHOULD BE MADE DIRECT TO THE APPROPRIATE PURCHASE AGENCY (NTIS). NATIONAL DISTRIBUTION CENTRES ITALY Aeronautica Militare Ufficio del Delegate Nazionale all'AGARD 3, Piazzale Adenauer Roma/EUR LUXEMBOURG See Bel lum 8 NETHERLANDS Netherlands Delegation to AGARD National Aerospace Laboratory, NLR P.O. Box 126 rj^ift
N0RWAY

BELGIUM Coordonnateur AGARD - VSL Etat-Majorde la Force Aerienne Caserne Prince Baudouin Place Dailly, 1030 Bruxelles
CANADA

Defence Scientific Information Service Department of National Defence Ottawa, Ontario K1A OZ3 DENMARK Danish Defence Research Board Osterbrogades Kaseme Copenhagen 0 FRANCE O.N.E.R.A. (Direction) 29, Avenue de la Division Leclerc 92,Chatillon sous Bagneux GERMANY Zentralstelle fur Luftfahrtdokumentation und Information 8 Munchen 86 Postfach 860881
GREE (

Norwegian Defence Research Establishment Main Library P.O. Box 25 N-2007 Kjeller PORTUGAL Direccao do Service de Material
da Forca Aerea Rua de Escola Usboa

Pditecnica 42

. ;^. _ r Hellenic Armed Forces Command D Branch, Athens

AGARD National Delegate TURKEY Turkish General Staff (ARGE) Ankara UNITED KINGDOM Defence Research Information Centre Slation Square House St. Mary Cray Orpington, Kent BR5 3RE

Attn:

ICELAND Director of Aviation c/o Flugrad Reykjavik

Microfiche or Photocopy National Technical Information Service (NTIS) 5285 Port Royal Road Springfield Virginia 22151, USA

UNITED STATES National Aeronautics and Space Administration (NASA) Langley Field, Virginia 23365 Attn: Report Distribution and Storage Unit (See Note above) PURCHASE AGENCIES Microfiche ESRO/ELDO Space Documentation Service European Space Research Organization 114, Avenue Charles de Gaulle 92200 Neuilly sur Seine, France

Microfiche Technology Reports Centre (DTI) Station Square House St. Mary Cray Orpington, Kent BR5 3RF England

Requests for microfiche or photocopies of AGARD documents should include the AGARD serial number, title, author or editor, and publication date. Requests to NTIS should include the NASA accession report number.

Full bibliographical references and abstracts of AGARD publications are given in the following bi-monthly abstract journals: Scientific published Scientific P.O. Box Maryland and Technical Aerospace Reports (STAR), by NASA, and Technical Information Facility 33, College Park 20740, USA Government Reports Announcements (GRA), published by the National Technical Information Services, Springfield Virginia 22151, USA

$
Printed by Technical Editing and Reproduction Ltd Harford House. 7-9 Charlotte St. London. WIP IHD