# The cosu trough-line test-process-interpreter

P. Decitre, Michel Depeyrot, Alain Jorry, M Moalla

► To cite this version:

P. Decitre, Michel Depeyrot, Alain Jorry, M Moalla. The cosu trough-line test-process-interpreter.
[Research Report] IRIA-RR-095, IRIA. 1975, pp.25. hal-04716079

HAL Id: hal-04716079

https://inria.hal.science/hal-04716079v1

Submitted on 1 Oct 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
RIA
laboria

Institut de Recherche
d'Informatique
et d'Automatique

Domaine de Voluceau
Rocquencourt
78150 - Le Chesnay
Tél. 954.90.20

laboratoire de recherche
en informatique
et automatique

The COSU Through-line
Test-Process-Interpreter

P. Decitre, M. Depeyrot,
Alain
A. Jorry, M. Moalla

Rapport de Recherche n° 95

Janvier 1975
# THE COSU THROUGH-LINE TEST-PROCESS-INTERPRETER

P. Decitre, M. Depeyrot
A. Jorry, M. Moalla

## SOMMAIRE

Les techniques et la terminologie de base sont énoncées afin de situer COSU par rapport au test du matériel d'un système informatique. COSU, générateur de test en Conversationnel Sous Usager de SIRIS-7/8 pour les périphériques des systèmes CII 10070 et IRIS 80, est alors présenté, puis quelques-unes de ses particularités de réalisation sont décrites.

Enfin, une réflexion sur les coûts et sur les marchés des systèmes de test est amorcée.

**Mots-clefs** : tests sous système, tests sous usager, interpréteur de processus, générateur de test, périphériques, analyse des coûts.

## SUMMARY

Techniques and basic definitions are proposed that help present COSU within the framework of Computer System Testing. It is a conversational Test process interpreter as a user processor under SIRIS-7/8 for peripheral subsystem testing on CII machines 10070 and IRIS-80. Its implementation aims and peculiarities are outlined, together with a cost and marketing analysis of test systems.

**Key words and phrases** : On-line Tests, Through-line Tests, Process Interpreter, Test Generator, Peripherals, Cost Analysis.
Acknowledgements

This article is a presentation of the COSU processor as a joint realization of ENSIMAG and LABORIA on a CII machine.

The authors wish to express their sincere thanks to all those who contributed to the success of the experiment. Started in October 1972 by Mr. DECITRE (Grenoble CII Scientific Center) and Mr. ROUX (CII Field Maintenance) under the responsibility of Pr. BOLLIET (Grenoble University), it was defined and its implementation was started by Mr. JORRY and Mr. MOALLA (ENSIMAG) ; interrupted in June 1973, it was completed and debugged by MMr. THIBAULT and VIGREUX (ENSMP) under the responsibility of Mr. JORRY and the guidance of Mr. DEPEYROT as part of a LABORIA project. Many enlightening discussions with Mr. MATROD of CII are gratefully acknowledged.

The authors wish to make it a symbol of Scientific cooperativeness.

Generous help by IMAG and IRIA computation center staffs also is gratefully acknowledged.

Most of COSU documentation was typed by Mme BARNY whom the authors wish to thank for the quality of her work including this paper.
# Table of Contents

I. Survey of Test Techniques for computer hardware.

I.1. Considerations on digital and electromechanical test systems.

I.2. Approach of peripheral subsystem testing.

II. Presentation of COSU.

II.1. Introduction to the test process interpreter.

II.2. Overview of COSU and the TL2 language.

II.3. Extension capabilities and maintenance intervention strategies.

III. Comparative Cost analysis of Test Systems.

## Bibliography
# I. SURVEY OF TEST TECHNIQUES FOR COMPUTER HARDWARE.

The aim of this paper is to present an operational software system for testing hardware peripheral subsystems without disturbing abusively customer operations in a computation center. Test techniques however have strong similarities, be they at the component level or at the system level. This paper hence starts with a survey aimed at proposing a framework encompassing previous automaton-theoretic as well as field-pragmatic approaches to hardware testing.

## I.1. Considerations about digital and electromechanical test systems.

In addition to the differences of approach of Industry and University specialists, test programs are usually classified according to a number of criteria : the kind of defects they aim at, the language in which they are implemented, the type of units they help repair, the operating mode, the kind of diagnostic messages, the usage frequency, the exhaustivity degree, etc.

Present technical or scientific literature does not help grasp globally the problem. The importance -in cost and difficulty- of check-out, acceptance and maintenance test design is only starting to overcome the lack of enthusiasm attached to hardware system testing and to incite such experiments at a level different from that of logic boards where standard Automaton Theory applies [20,31].

### I.1.1. Kinds of defects aimed at.

The distinction between *deterministic* and *random* (or intermittent) defects is intuitive and classical. It is not however as fundamental as the distinction between *error* and *failure*. In complex systems deterministic defects often have a random appearance (simultaneity incidents...), and it is often sufficient to apply lower level programs (microdiagnostics) to detect them deterministically. An error is a design or adjustment defect, while a failure is a component or manufacturing-process defect. Oftentimes however errors induce failures which it is useless to repair unless the error itself is corrected.

### I.1.2. Burn-in, wear-out and test.

A *test* is an action aimed at detecting the presence of one anomaly. A *diagnostic* is deduced to express the presence or the absence of this anomaly.
The purpose is to design the action (test) that can result in the most effective diagnosis (revealing the largest number of defects associated to the anomaly).

According to the curves displayed on figures 1 and 2, three phases must be distinguished along a product life.

<figure><img src="image_2.png" /><figcaption>Figure 1. The Survival plateau.</figcaption></figure>

<figure><img src="image_3.png" /><figcaption>Figure 2. The failure frequency or "bath-tub" curve.</figcaption></figure>

Transitions between these phases are called respectively **burn-in** ($α → λ$), whereby infantile mortality is gotten rid of, and **wear-out** ($λ → ω$), whereby aging decay occurs. Test programs should induce neither of these transitions but should be able to ascertain that a product has reached the survival plateau, and through some replacement-repair policy they should be able to postpone wear-out phase ω.

Diagnostic historical log-outs should enable trend analysis permitting corrective actions during a product life through early **prognostic** hints.
### I.1.3. Test languages.

Test language instructions can differ from instructions for standard use and must be specific to a given object under scrutiny, since a test program is with respect to the object what a mould is with respect to a molded object, or what a negative is for a photographic picture. Meanwhile all usual programming levels are to be encountered in testing, from microprograms to system-writing languages, via machine-code protests or decision tables. There are many similarities between Real-time programming and Test-programming, where decision table coding has traditionally been called "Fill-in-the form programming", and where systems are custom-designed to a large extent [28,30].

Whenever test program translation is performed interpretively, the translator is called a Test and Diagnostic Program *Generator* (TDPG). The COSU system hence is oftentimes called a generator although it is capable of monitoring a compulative translation followed by a separate and repetitive execution of its object-code as well as monitoring jointly translation and execution as an *interpreter*.

### I.1.4. The Object under test.

Computers are especially attractive for a test theory because of their topologically hierarchical structure, so that the object under scrutiny varies between the unmounted digital integrated or discrete circuit and the computer network, via logic board, and processor cabinets. *Interconnections* between logic elements can themselves be the object of a test : printed circuits, back-panel wiring,... Hence test programs can be granted a hierarchical structure fitting that of the computer they aim at, as well as that of the production process. It is by the way noticeable that fabrication methodologies should ban the term "production-line" in favor of the term "production-flow" since the structure is that of a *tree*.

### I.1.5. The operating mode.

A *process* now is usually defined as the execution of a program [23]. On the other hand it is classical to call *stimulus pattern* the set of input data
used for diagnosis. Hence a *test process* is defined as the execution of a test program for a given stimulus pattern.

Diagnosis can be _dynamical_ if based on intermediate output data resulting from the test process or _static_ if based merely on the final response pattern. The former category includes protests with halt-on error and iterate-on-error capability or with the facility for switching into static diagnosis upon error [1,22].

### I.1.6. Diagnostic kinds.

Proper inference of failure diagnosis from a test process response requires that a given portion of hardware be operational, so that a test sequence is _thruthful_ only within a specific program context. This makes mandatory elaboration of a _penetration graph_ and the choice of a test tactic over it: such a graph indicates for every subunit-node which other subunits must be operational for a given test sequence to be truthful as labeled on arrows pointing to other nodes [27].

Four kinds of diagnostic can be proposed :

a) _functional_ when the aim is to verify conformity of the object with equipment specifications at the standard operating interface (soft/hard) [3,6]. (*)

b) _parametric_ when the aim is a set of performance measurements or transferometric evaluation [2,7].

c) _referential_ when the test and diagnostic program refers the operator to an intervention procedure guiding him through replacement or repair [4,13,29].

d) _localizing_ when the program specifies failure location up to the interchangeable element to be replaced or up to the adjustable element to be tuned [8,15,24].

### I.1.7. Frequency of use.

Frequency of use of a test program or subprogram is a function of the check-out strategy in production and of the maintenance strategy in the field. It can make economical reuse of the same program in various modes in diverse situations :

a) _Preventive_ operation, before incident was even noticed, is performed during production and in periodic maintenance.

<footnote>(*) i.e. when the anomaly is denounced through the functions it alters.</footnote>
b) *Curative* operation after incident detection and during repair.

c) *Acceptance* operation at the end of production line and after replacement or modification in the field.

From the repetitive use of the same program in time and space, trend analysis and averaging can provide the producer with a reliable failure prediction and interpretation data base [11,14].

<figure><img src="image_4.png" /><figcaption>**Figure 3.** Synoptic decomposition of system interconnections.</figcaption></figure>
## I.2. Approach of peripheral subsystem testing.

The case of peripherals is paradigmatic since all potential test difficulties are encountered in them : they include analog, digital and hybrid sub-units and reveal electromagnetic and electromechanical troubles.

### I.2.1. Categories of Tests.

Test programs of a peripheral subsystem can be entered into diverse categories according to whether it is connected in standard operating conditions, as a whole or in parts.

If not, test is said to be *external*, but this may imply :

a) on a *tool-system* for the whole subsystem (controller, device and storage),

b) on a *tool-controller* specific to production check-out for the electromechanical device and storage support (this controller might be already amortized and/or activated by a cheaper CPU than in actual field operation),

c) on a *maintenance processor* isolated as a tester whenever the system in the field has a reconfiguration capability,

d) on an *acceptance tester* for the storage support in the case of electromagnetic devices (discs and drums),

e) on a *hardware-monitor* for every electronic unit under performance measurement.

If on the other hand the peripheral subsystem is connected in normal operating conditions, test is said to be *internal*, which encompasses :

a) An *autotest* for a microprogrammed controller checking itself,

b) A *microtest* for a microprogram designed in some subunit for testing an other one and emitting a microdiagnostic.

c) A *protest* for a test program implemented at the standard soft/hard code level.

Internal autotests tend to disappear and to be replaced by microtests executed by a maintenance processor. This eases resolution of the *hardcore dilemma* in finding a thruthful test path on the penetration graph (§. I.1.6.). As a generalization, it may be stated as the INVERSE POWER PRINCIPLE that the amount of processing power required in the tester is inversely proportional to that of the subsystem under test [11].
### I.2.2. Operating classes.

Finally test system can be classified into six classes according to their degree of interference with standard operation of the object system user.

a) STAND ALONE for autonomous protests in privileged mode dedicated to one kind of objects to test like a decimal arithmetic unit or a tape drive, and incorporating its own operating mode routines. [ 6 ].

b) OFF-LINE for protests dedicated to specific objects to test but sharing common operating mode routines (like interrupt processing, file management, operator dialogue, iteration-on-error,...) in an _independent test monitor_ [ 1 ].

c) THROUGH-LINE for restricted protests with no other privileged capability than that granted by the standard Operating System to real-time users, hence granting under a test processor system maintainability with no halt to Computer System operation in the field. [ 33 ].

d) OUT-LINE for external microtest by maintenance processor, able or not to dialogue with the operating system or the service console, granted special hardware paths like the Diagnostic Shift Register [ 29 ] to force initialization and stimulus patterns and to collect response patterns.

e) ON-LINE for multiprogrammed execution of protests and user programs under operating system control with the former being granted secure use of privileged instructions by a _test monitor_ supervising them as a real-time processor under the operating system. [ 5,18 ].

f) IN-LINE for multiplexed microtests capable of simultaneous execution with standard microprograms of the system instruction code, hence letting test and user operations be paralleled under operator control without operating system control. [16,19].

For each of these classes, protests can be preprogrammed or can be interactively generated and translated interpretively. An evolution happened from stand-alone preprogrammed protests toward test monitors managing several subsystem
protests and substituted to the operating system during maintenance, then toward
test monitors integrated as processors within the operating system.

COSU is innovative with that respect since the monitor is not integrated
within the operating system but put under its supervision as any other real-time
task. Moreover it supports an interactive TDPG granting both test program and test
process generation as well as diagnostic generation.

The test program generation part subsumes an interactive *editor* with
question answering facilities. The test process generation part subsumes the ca-
pability of inputting test stimulus pattern *conversationally* as well as other
parameters into preprogrammed and catalogued protests, before or during its exe-
cution.
## II. PRESENTATION OF COSU.

COSU is first of all the common kernel for all input-output THROUGH-LINE protests of the IRIS-machines under SIRIS-7/8. [9,10].

### II.1. Introduction to the test process interpreter.

This kernel has been designed as a set of procedures called through a simple language TL2 for Through-Line Test Language (TLTL), this kernel appearing to the system as a standard user. COSU is a prototype (experimental but full-size and operational) that aimed at offering the maximum amount of serviceability to enable SIRIS-7/8 but also at helping define the minimal alterations to bring to SIRIS-7/8 or any other operating system to give Through-Line protests the same potential efficiency as that of on-line protests.

Test system trends since the appearance of microprogrammed peripheral controllers are toward separating microdiagnostics executed in-line locally and restricting to on-line the compatibility and parametric (or functional) protests written in a higher level language. COSU tends to exploit this trend but it also serves a new purpose : that of facilitating telemaintenance, i.e. distant and interactive activation and analysis of tests without disturbing the operating system.

#### II.1.1. General objectives.

The initial problem is the following : can a test program for peripheral subsystem be executed as any other system user program ? If so, what is the cost [21] of implementing a conversational multiprogrammed monitor in slave-mode with respect to SIRIS-7/8 and helping write, archive, modify and execute conversationally channelprograms for input-output check-out (SIRIS-7/8 is the Operating System for CII machines 10070 and IRIS-80, comparable respectively to a Σ7 and a 360-67).

#### II.1.2. Project funding.

COSU was started under the initiative of CII Scientific Center in Grenoble (P. DECITRE) in order to study the minimization of maintenance time in the field
for preventive or curative operations.

System definition (A. JORRY, M. MOALLA) lasted from December 1972 to June 1973. Implementation and check-out were performed in two phases separated by a wait phase due to problems encountered in SIRIS-7/8 operations. The first phase at ENSIMAG (A. JORRY, M. MOALLA) lead to the test program generation part. The second phase (A. JORRY, J. THIBAULT, G. VIGREUX) at IRIA lead to the test process generation part and the overall debug as well as to a complete documentation (July-August 1974) within a LABORIA project (M. DEPEYROT) after some objective rethinking.

Phase one (March-June 1973) cost about 8 man-months.

Phase two (May-June 1974) cost about 3 man-months.

## II.2. Overview of COSU and the TL2 Language.

It appears that a proper structuring of such a through-line conversational monitor can only be performed with the aid of a rigorous language decomposition.

### II.2.1. Basic organization of COSU.

The decision was made to organize the program generation around a channel program writing language that could either be assembled into machine-code or directly interpreted.

Interpretation is cumbersome and time consuming for this type of language and raises difficult error-detection and memory-reservation problems unsolvable under SIRIS-7/8 where channel operate with real addressing and user programs should know virtual addresses only. COSU must hence operate in both addressing modes, it must in particular transform virtual memory areas granted to it by the operating system into real memory areas for channel operations.

For instance, let be transfer order require the printing of words 'AAAA' and 'BBBB' on a line-printer. If COSU requires two virtual memory words for putting these data, their virtual addresses are x and x+1, while their real addresses are
y and z, randomly distributed. The channel will however assume that z = y+1 which is quite unlikely.

There are two possible solutions : either transforming the single transfer order into two transfer orders for 'AAAA' and 'BBBB' separately (which is the SIRIS-7/8 solution) or guarranteeing that if $y = f(x)$, then $z = f(x+1) = y+1$ i.e. that memory translation is a **linear operator**. This latter solution has been adopted by COSU. The former solution puts the stress on transfers only, the latter puts it also on **transfer modes** which is a mandatory concept for testing where 'AAAABBB' should be transferred at once.

Resolution of the addressing problem is performed partly at **assembly-time**, when the list of input-output programs where such problems arise is established, partly at **loading-time** through proper program inputting (data and orders for channels have to be put in contiguous memory areas in real space) and finally at **execution-time** when object code virtual addresses are converted into real addresses.

**Direct assembly** into machine code would have raised the problem of protecting COSU against programming errors in programs it would monitor. This is why it has been decided to assemble the TL2 source language first into an intermediate code to be interpreted by the **executor** in COSU.

<figure><img src="image_5.png" /><figcaption>**Figure 4.** Synoptic presentation of the Language hierarchy.</figcaption></figure>
### II.2.2. Inputting and archiving of protests.

It was decided to input protests written in TL2A via a typewriter controlled by the Transmission Management System (SGT of SIRIS) and stored on disc by the File Management System (SGF of SIRIS). Object protests written in TL20 are also to be stored on disc and COSU is in charge of handling a catalog of external names for protests and their characteristics. Commands related to this task in COSU form the sublanguage TL2C édi.

### II.2.3. File modification and programming facilities.

A conversational editor was designed and checked-out in order to help modify programs and, above all, to simplify channel-program writing thanks to a set of questions and controls. A user must indicate he plans to write a channel-program so that the editor asks him to fill-in the specific data required (peripheral address, orders, indicators,...) and to translate them into TL2A. Commands related to this task in COSU form the sublanguage TL2E : they provide a truly conversational Test and Diagnostic program generator (TDPG).

### II.2.4. Loading and executing programs.

When a user wishes to start a program execution it warns COSU with a command from sublanguage TL2C. Hence COSU takes in charge the task of providing the necessary storage space through its memory handling module ; this is an important task considering the fact that central units of IRIS machines supporting SIRIS-7/8 operate with virtual addresses.

### II.2.5. Conversing and Test guiding.

Languages TL2A and TL20 contain test instructions (CMPARE, SI) for conditional branching that grant automatic routing of protests according to peripheral subsystem reactions.

They also contain an instruction for putting the program in a state of wait on commands (conditional or not). This instruction combined with commands of the interpreted sublanguage TL2I help the user guide test sequencing (i.e. suspend execution, restart from any declared point, halt) or to obtain information about previously received results.
### II.2.6. Multiprogramming and coordination of asynchronous parallelism.

Recall that COSU should help execute several protests in parallel with user programs and with each other. The point is to take advantage of the fact that such input-output protests rarely make use of central processing units during their execution so as to activate as many of them as possible in parallel. This is why a supervisor was added that takes care of coordinating execution of the various modules previously enumerated, execution of these modules with that of protests and of managing synchronization, wait events and wake-up events of input-output end.

<figure><img src="image_6.png" /><figcaption>Figure 5. Overview of COSU Architecture.</figcaption></figure>
## II.3. Extension capabilities and maintenance intervention strategies.

Let the K symbol mean 1024 for $2^{10}$.

COSU is a METASYMBOL package of 7000 instructions or 40 K bytes of code. For the time being it operates with no overlay, hence imputing 60 K bytes of memory (out of which 20 K due to SIRIS). An overlaid version would only impute 10 k bytes (3 K resident, 2 K for swapping, 5 K for SIRIS).

### II.3.1. COSU operating mode.

COSU operates in slave mode, only using from privileged mode the right to program protest input-output programs at the channel level via a SIRIS privileged procedure, the `Execute Channel Program` macroinstruction `M:EXCP`, which allows asking `SIRIS-7/8` for execution of the channel program passed by parameters.

It manages a limited variable number of tasks (parametrized limit fixed today at 10) of limited variable storage size (parametrized limit fixed today at 12 K) and with random memory location. At the `TL20` level, addresses are given as base-displacement pairs. Protests are divided into 2 K byte pages, each of them corresponding to a base register (among 128:2 = 64 registers for the time being), and they are located randomly within the physical storage space, except for specified memory areas that must be contiguous and must hence be located within blocks randomly distributed themselves.

It manages a library of at most 30 files (parametrized limit) each of them including a `TL2A` source file and a `TL20` object file.

A user in front of its console has at his disposal the `TL2C` command language for dialogue with the COSU processor including 18 commands allowing the call of its various modules, and has at his disposal the intervention language `TL2I` interpreted with six commands helping to guide test sequencing conversationally. `TL2E` is a classical Editor language augmented with the call command for the procedure to help in writing channel programs. `TL2A` is limited to 13 assembled instructions. All of these sublanguages are extensible by simple means.
### II.3.2. Extension facilities.

The first kind of extension consists in offering a more intimate contact between COSU and every peripheral subsystem, in particular for timing control, both for the peripheral controller and the peripheral device timings. This kind of extension is realizable through an increase in the number of parameters transmitted to SIRIS-7/8 together with the channel program to be executed. It would facilitate simultaneity testing at the system level where proper interactions between devices on a single controller or between subsystems on the same channel could be checked.

The second kind of extension is the facility to allocate and disallocate peripherals dynamically under SIRIS-7/8. In order to protect the system against deadlocks, this facility is reserved to the operator (LOCK/UNLOCK) and merely for disconnecting faulty peripherals. It would be an important improvement if SIRIS could grant this same right to the maintenance operator through COSU thanks to the definition of a new peripheral state for TEST.

The third kind of extension is the possibility of using the operator console as COSU conversational peripheral instead of a standard user typewriter under SGT.

The fourth kind of extension is the means for COSU to start microtest execution in-line within peripheral controllers and to collect their microdiagnostic messages eventually.

Finally a useful complement to COSU would be a failure dictionary with self-learning capability facilitating automatic diagnosis development as described in [32].
### III. COMPARATIVE COST ANALYSIS OF TEST SYSTEMS.

It is not feasible to present here all basic facts concerning test system cost as analysed in [32]. It is however fundamental to grasp the underlying ideas through the four following cost curves. [25,26].

The first one on figure 6 displays the cost of debugging protests programmed in machine language according to whether they are executed alone, multi-programmed with the system only or multiprogrammed with other user tasks.

The second one on figure 7 displays the relative position of a system like COSU with its higher-level generation language.

The third one is a composition of the first couple of figures with complement to display on figure 8 the six cost lines for two programming levels and three degrees of parallelism.

The fourth one on figure 9 displays the cost increase of diagnosis according to the test operating mode and to the difficulty of reaching a diagnostic as evaluated with the number of elements to be tested since this number is a function of diagnostic degree of refinement and of the number of potential failures. Four break-down points are noticeable : the first break-point is where in-line microdiagnostics become necessary, either because there are too many faults for the penetration graph at the program level to be truthful, or because a finer level of localization is desired ; the second break-point is where off-line testing becomes necessary because maintenance time lost through multiprogramming is too important, in particular if an efficient protest requires commanding the peripheral subsystem orders contradictory or unauthorized by SIRIS ; the third break-point is where the peripheral subsystem is no longer reachable by program ; the fourth break-point is where even microprograms are no longer executable.
<figure><img src="image_7.png" /><figcaption>Figure 3. Comparative cost analysis of parallel processing in pattern development and testing.</figcaption></figure>
<figure><img src="image_8.png" /><figcaption>Figure 1. Cost advantage of the topologic test at a diagnostic laboratory.</figcaption></figure>
<figure><img src="image_9.png" /><figcaption>Figure 8. Comparison of costs of generati on and parallelism.</figcaption></figure>
<figure><img src="image_10.png" /><figcaption>Figure 9. Diagram showing variation in number of variations possible with segregation in order.</figcaption></figure>
By its low design and check-out cost, by its testing facilities and power, by the low cost of the extensions that would make it as powerful a tool as any other presently available, COSU has proved that THROUGH-LINE testing should play an original role within test techniques. [12].

In particular, portability, evolutivity and modularity (together with a hierarchical design) which are its first characteristics, Through-line input-output testing corresponds to the need to shift the emphasis on cost decrease from design to production and maintenance, the former being mainly financial for the manufacturer, the latter being even more psychological for the customer. [17].

Required Periodicity of preventive off-line maintenance visits according to test monitor nature :

<table><thead><tr><th>STAND-ALONE OR OFF-LINE</th><th>ON-LINE OR IN-LINE</th><th>THROUGH-LINE</th></tr></thead><tbody><tr><td>1 day (D) per week (W)</td><td>1 day/ month (M)</td><td>1 day/ dozen</td></tr></tbody></table>

<figure><img src="image_11.png" /><figcaption>Figure 1. Relative Cost efficiency in operation.</figcaption></figure>
[1] R. SUDA. "An application-oriented multiprocessing system. PART V. The Diagnostic Monitor". IBM Systems Journal. Vol. 6. n° 2. pp. 116-123. (1967).

[2] J.M. SMITH. "A review and comparison of certain methods of computer performance evaluation". The Computer Bulletin. pp. 13-18. (May 1968).

[3] J.J. DENT. "Diagnostic Engineering Requirements". AFIPS. SJCC. 32. pp. 503-507. (1968).

[4] A.N. HIGGINS. "Error recovery through programming". AFIPS. FJCC. 33. pp. 39-43. (1968).

[5] G.W. NELSON. "OPTS-600 on-line Peripheral Test System". AFIPS. FJCC. 33. pp. 45-50. (1968).

[6] M.S. HOROVITZ. "Automatic Check-out of small computers". AFIPS. SJCC. 34. pp. 359-365. (1969).

[7] M.E. DRUMMOND. "A perspective on system performance evaluation". IBM System Journal. Vol. 8. n° 4. pp. 252-263. (1969).

[8] N. BARTOW, R. Mc GUIRE. "System/360 model 85 microdiagnostics". AFIPS. SJCC. 36. pp. 191-197.a. (1970).

[9] C. BOULLE. "Certains aspects de réalisation de SIRIS-8" in Congrès AFCET d'Informatique. PARIS. pp.1.1.59 à 73. (September 1970).

[10] B. CHUET, S. SELETZKY. "Système de fichiers à structure hiérarchisée pour les ordinateurs IRIS dans un contexte "on-line" et multiutilisateur" in Congrès AFCET d'Informatique. PARIS. pp. 3.2.-151 à 159. (September 1970).
[11] J.E. STUEHLER. "An integrated Manufacturing Process Control System : Implementation in IBM Manufacturing". IBM. J. of R. and D. Vol. 14. n° 4. pp. 605-613. (November 1970).

[12] W.B. JOYCE. "Organizations of Unsuccessful R. and D. Projects. IEEE-EM-18. n° 2. pp. 57-65. (May 1971).

[13] D.L. DROULETTE. "Recovery through programming System / 360 - System/370". AFIPS. SJCC. 38. pp. 467-476. (1971).

[14] L.A. BELADY, M. M. LEHMAN. "An introduction to Growth Dynamics". Brown University Conference on Statistical Methods for the evaluation of Computer System Performance. (1971).

[15] A.M. JOHNSON. "The microdiagnostics for the IBM System/360 model 30. IEEE-C-20. n° 7. pp. 798-803. (July 1971).

[16] J.W. IRWIN, J.V. CASSIE, H.C. OPPEBOEN. "The IBM 3803/3420 Magnetic Tape Subsystem". IBM J. of R. and D. Vol. 15. pp. 391-400. (September 1971).

[17] L.A. BELADY, M.M. LEHMAN. "Programming System Dynamics or the metadynamics of Systems in Maintenance and Growth". IBM Research Report. RC.3546. (September 17, 1971).

[18] P.J. SCOLA. "On-line computer-Testing system". Second workshop on "Fault-detection and diagnosis in Digital Systems". LEHIGH University. pp. 103-114. (December 1971).

[19] G.R. AHEARN, Y. DISHON, R.N. SNIVELY. "Design innovations of the IBM 3830 and 2835 Storage Control Units". IBM J. of R. and D. pp. 11-18. (January 1972).

[20] R.J. PREISS. "Fault Test Generation". Chap. 7 in "Design Automation of digital systems". Vol. I. Edited by M.A. BREUER. PRENTICE HALL. (1972).
[21] R.E. MERWIN. "Estimating Software Development Schedules and Costs". IXth DESIGN AUTOMATION WORKSHOP. IEEE. pp. 1-4. (July 1972).

[22] IBM Systems. "OS/VS OLTEP : on-line Test Executive Program". GC 28-0636-1. (1972).

[23] J.J. HORNING, B. RANDELL. "Process Structuring". ACM Computing Surveys. Vol. 5. nº 1. pp. 5-30. (March 1973).

[24] H.Y. CHANG, R.C. DORR, D.J. SENESE, T.L. SMITH. "Maintenance Techniques of a microprogrammed self-checking Control Complex for an electronic Switching System". IEEE-C-22. nº 5. pp. 501-512. (May 1973).

[25] B.P. DZIELINSKI. "A guide to financial planning tools and Techniques. IBM Systems Journal. Vol. 12, nº 2. pp. 126-144. (1973).

[26] M. AISO. "Forecasting Techniques". IBM Systems Journal. Vol. 12, nº 2. pp. 187-209. (1973).

[27] J.D. RUSSELL, C.R. KIME. "On the diagnosability of digital Systems". in Proceedings of the "Fault-Tolerant Computing Conference". pp. 139-144. (June 1973).

[28] F. BANCILHON et al. "Principes de Conception Automatique dans le Système SPECTRE". RAIRO. 7e Année. B-3. pp. 31-62. (Octobre 1973).

[29] A. TOTH, C. HOLT. "Automated Data-Base driven Digital Testing". IEEE COMPUTER. pp. 13-19. (January 1974).

[30] U.W. POOCH. "Translation of Decision Tables". ACM Computing Surveys. Vol. 6. nº 2. pp. 125-151. (June 1974).

[31] F. BANCILHON, M. DEPEYROT. "Identification des automates non-fiables".
[32] M. DEPEYROT. "Computer component and system testing as a part of Computer Aided Production and Maintenance. Rapport de Recherche LABORIA n° 83. (1974).

[33] A. JORRY. "Le processeur COSU sous SIRIS-7/8, un interpréteur de processus de test des entrées-sorties". Rapport de Recherche LABORIA n°94. (1974).