The interface between designer and maintainer

M. W. Young

The i nterface between designer and maintainer The usual aim of computer-aided design is to bridge the interface between design and production. However, an interface also exsists between design and maintenance. The author of this paper introduces some concepts, which are currently being considered, for improving design for maintainability with manual design processes and indicates their potential development for use with c-a.d, systems.

Computer-aided design in the electronics industry is evolving from a collection of discrete programs into integrated design systems which aim to bridge the interface between design and production. An interface also exists, however, between design and maintenance.. This has always been a difficult and neglected area because the designer works on the same firm as the producer, whereas the maintainer is often part of the customer's organisation. If computer-aided design can help to bridge this gap between designer and maintainer, great improvements in maintainability of the resulting equipment could be possible. This paper introduces some concepts which are under consideration for improving design for maintainability for use with manual design processes and indicates their potential development for use with computer-aided design systems. There are two main approaches to better maintainability. These are: a. to improve manual testing and fault finding, b. to exploit automatic testing and fault finding. The manual fault-finding approach further sub-divides into: a. improved documentation in service, b. improved equipment design by better documentation development. Each of these approaches depends on the others. Each will be briefly described in relation to manual design before considering their extension into computer-aided design.

Documentation in Service The aim of documentation in service is to transfer technical information from designer to maintainer. There are five basic principles involved in the transfer of technical information. These are: a. Establish a Structural Hierarchy. Various levels can be chosen for the hierarchy, such as System Equipment Sub-unit and Printed Circuit Board. The succeeding stages need to be applied at each level. b. Isolate the Signal Flow. This may be straightforward, as in the case of simple communications receiver SUMMER 1970

when one major signal flows through the equipment. As the level of complexity builds up it becomes more difficult, and more important to isolate the signals if technical information is to be conveyed clearly, especially when several modes of operation may be involved. c. Isolate and Explain the Functional Elements. The functional elements will vary depending on the level of the hierarchy which is being discussed. Broadly, however, they will correspond to the blocks of a block diagram. Any group of things which perform some recognisable functions can form a functional element. These groups need to be isolated and described. d. Show how the Functional Elements depend on each other. This highlights what is important in the block diagrams from the point of view of the person receiving the information, and it deepens his appreciation of the significance of each functional element in the overall system. Furthermore it draws attention to interfaces, and shows the consequences of the failure of any functional element. e. Specify the Signal between each Functional Element. This finally specifies all the interfaces and also defines what each functional element must do, since a full specification of the input and output signals specifies the function of each element. If these principles are applied, a clear and concise description of the technical characteristics of a system or equipment will exist and be capable of transfer to anyone who needs to know about them. There may be supplementary data required on specific topics, but the o v e r a l l purpose and characteristics of the equipment will have been established. A number of documentation systems exist which apply these principles in varying degrees. The one described here is known as the Functionally Identified Maintenance System (FIMS) and is under consideration for use in the Royal Navy. The essential features of F I M S are the use of block 33

Sowtooth q e n e r o t o r - unit 12

r

tSR22 ~M , .

/

.

. s.,tc,

+

|

Y ~wzoro

w.___r~-

p,,,s,

2~

.-,~-i~)

,

L_ Rv.,, /

|

/

|

i

%"~2 ~Ok:,-.~vv~

r77

swit:..u~s.

|

',~M

I

_-"

'

-

-'- " r ...........'~'T~;................. ' " " + ' ' "

cosBBov =pL 21_ _ __ -=-_~_""="="~"""="=""""''m"'''"""''" _

"'"w"""''""''''"+

l

~

nlnlAlll1~l~l~nlll~lllmlll~llilfnlim umui~diit immwu~liin~im, i

--

R5 120k

Alternate ~-~.~-~-~--~ cos80V ~L~.~ ~ ~].

Sw~'chpulsL

i

;,,,,._]~

T /

•

!

I

ScQncentre PL1.3 s~.onit~oI

)

Open centre--PL1.;Sn

~.

s.u.itlo-

ii i

Switch pulse

"1

,1__ R.3.

.

i !,2

.

.

_

.

2Jr a

( ~

44 ~

~

.

Z-"

.R]'

~°°kj .

'+ t'

+• , ( ~

PL3.16 I

~ll~3

•

V,b'

I , l,

R4!74k~ I ~ W Z _ 7 - ,

;

T

i f+"

~##k

l

IC5o-~

/|

T I + I~+~

.

t

I t

,1"

I

^)AIvI^ I .

.

=

/l I |

Lv~5

j

,v,.

~8

"++ ~

.

'Y' Position

'

I:

I _ •

At

....................................................

v-mt-I

!

C23

0

o=oL ,,+o++! .' . Y

'I

,~,,,,~,t~

P

~

llC~ o.oo~9

....~m...,,.,,,,.,,,...,.,,,,.,,,,,.. .........]''~TNeep flybock |

L -~

i

I

~~1-,-

R4868k

C321

Ii =

9

,c~o.oo~

= ~

C~5

I

I

II

i41' 0-0039 I 560 I! i R-92 +I + ~ ~ CiVil--

I ~

,

'

,

~IIII~IIIlIIIIIIIIIIHIIIIIMIIIIIII~IIIIIIIIIIIIIIIIIIIIIIIIII~ C20110001 -- I I

~SK 2 6 I:) SK 2.5

~"

External,

i

scan /

L

/

|

:.

R37 27k

Clg ~ •••••••••••g••1t••••••••!•u•••••••••

lltlllllllllmal

) SK 2.4

'Y'Unexpanded_PL 1.5 marker input -+300V Stab .-- PL1-18 . . . . ~~. . . . .

Suo~,,es

J

At earth-~/ .._ PC 113 -

IR32 ~R27

PL 1.7 V6a&b

6.3V

{~22 4t 3~V2a&b 4~ 3~V5a&b

11

t3~V8

1

- 300V Stab | ----PL1.6

Above. Fig. la. 34

Right• Fig. lb. COMPUTER AIDED DESIGN

diagrams, block text and dependency charts in a functional hierarchy. Figure 1 shows the forms of the block diagrams, with functional blocks shaded. To describe this diagram, block text is used, laid out in the same pattern and placed opposite the block diagram. These diagrams are arranged to show the signal flow lines clearly, from left to right, with feedback lines going from right to left. Each pair of block diagrams is supported by a dependency chart. This is essentially another way of drawing a block diagram. That is to say it shows functional elements, their inputs and their outputs, and the way in which they

are connected together. However, it does this in a way which highlights the dependence of the functional elements along the signal flow line and which allows the specification of the signal between each element. This involves the following basic symbols, shown in Figure 2. Functional Elements are shown as dots on maintenance dependency charts. The output of an element is termed an 'event', which occurs if (a) the functional elem~at is working correctly, and (b) the inputs are all correct. Events are represented by boxes, in which a brief description of the event appears.

Sowtooth g e n e r o t o r - u n i t 12

lullIIIIIIIIIIIIIIIIIIIIIIInlllflllllllllllllllllllllllllltilnlllllnllllllInlllIiiIiiiIli11111111111111111 iiiiiiiiiiiiiiiiiiiiiIIIIIIIIIIIIIIIIIIIIIIIIII~ i Elect ronic switch circuit ~ controlled by switch pulses I B & B', closed during _---=f l y b a c k (conducting)ondopen ~ Uduring scan periods. :i

N - P o t -1 -=

i i

~Output pQtential toV-lnt-I ~ Switch pulse ~ during f l y b a c k p e r i o d is B" m~---~_Z_zdeterm,ned by p o s i t i o n o t

PL3.3

PL3.4 Switch pulse B

~-

~i

:~, -==-

i

| N-Pot-1.

~,

"

----Thus s e t t i n g s t a r t i n g level of next sawtooth.

~

i

i

i ~'~,,'. "~,,....... ~-~,-~-~~:~.-~.~,

~_

'

~

PLY1

i

~

H

~

n

~

~

~

i

~

~

1

1

~

.....................................................

miller

Cos B0V----

integrator

| W h e n both V-SW-1

and V - S W 2 | a r e non conducting t h e ~ w t o o t h |produced ha5 a duration dependant

Alternate ----" Cos 8 0 V PL2.7 Switch pulse -SW-2 ..........................................................'" ...................................................................................... i A PL3.15 | Electronic switch c i r c u i t controlled by s w i t c h pulses A &A" closed during tlyback (conducting) -~

~ andopen during scan period. A proportion of the cosine input controlled by Nmpot-2 is applied t o V - l n t . - 1 t o s e t t h e sawtooth

~

Scan centre Sw. unit 10 c e n t r e PL115==== scan s t a r t level in open c e n t r e c o n d i t i o n . Open Sw. unit 10 __== Switch pulse _-== • A'

'•n•':•' A~c~sas a ........

-

|upon position of Sw-1 and | amplitude dependant upon instantaneous value of cosine input

!

! _:_==

_-= i I

i

PL3.16

i

_J

__-__-

.~:~.~,~ ~.-~ . ~

ilN-Pot-2 'Y'Position

PL_1_.16_~ ~

~nput --=-----------------~: ~ ~'~ PL1 .17J =,..

-

=

?

= ~

~

-==- I ~

~

-----=l-

~="

--~ ~ i --=

i

~--o __--

.

i | i

! t

~.,..,..,,.,,,m...,.............,,............~l~ I i

Sweep f'ybock

_Z---Water o f r a n g e switch. - S e l e c t s c a p a c i t o r 0nd

-== -

-fOrms part of discharge -==path of rangecopocitors

~ _==

=set by - V-Int-1

i

S - l b and (flyback period).

i--_____ i ==

Z_-=Z

- W a f e r o f r a n g e switch. " Selects m i l l e r c a p a c i t o r t a r

i

t

__==

required range and ,arms part i of' charge circuit.(scan period)

~IIIIIIII111111111111111111111111111111111111111111111111IIIMIIII]~ i

%tS2o, j

SK2.6

s~2.s

i

:

! !

| -

.~""'"''''''"'''''"'''''"''''''"'""'"'''''"'''''""''"~''"'''"'""f"" t

LsSK2.4 Y Unexpanded_ m a r k e r input --PL1.5

SUMMER 1970

35

Tlie inputs to a functional element depend upon previous events, and are shown by d e p e w l ~ e y markers. These are represented by triangles. With these symbols dependency chains can be built up. The block diagram is equivalent to the statement 'the input signal is operated on by the function to produce the output signal'. The dependency chart is equivalent to the statement that 'the output signal will be present if the input is present and the function is correctly performed'. It is the difference in emphasis between these statements which highlights the difference between the block diagram and the dependency chart, although both convey essentially the same information. Using these symbols, complete dependency chains can be drawn, as in Fig. 3. Along the top of the dependency chart the functions and signals are referred to the block diagram and to the table of signal specifications. The chart can now be used to fault-find using the 'half split method', illustrated in Fig. 4. This description of F I M S has been necessarily brief and incomplete, and no mention has been made of the hierarchy of these diagrams giving more detail at each level, nor of the supporting spares lists, etc. The ideas of signal flow and dependency upon which F I M S is based are very general. They can be applied to electrical or mechanical hardware, or computer software, or to describing an organisation. They can also be applied to the design of an equipment. This gives rise to the concept o f D D S (the Development Documentation System).

Documentation During Development D D S is the use of the F I M S format as a documentation system and design aid during development. This means

that handbook writing is effectively started with development and although many changes occur before final publication takes place, the roots will be firmly in the development phase, with a consistent format running throughout. Since the D D S / F I M S format specifies the signal between each functional element, it can also be used to keep track of interface problems and to specify tolerances. But a

Output 2

Input1

The block diagram makes the s t a t e m e n t : "Input 1 is operated on by t r a n s f e r function ~ to produce Output 2 "

1

Z

L

2

I "w

I

1

The dependency chart makes the statement :" O u t p u t 2 will be present if t r a n s f e r function ~ is c o r r e c t and input 1 is available" Indicates the blocks of a block diagram ~

J A

nclicntes events OCCUrring as the inputs or outputs of blocks Tndicates the dependence of an input to a block on some previous e v e n t

F / g . 2.

more important use is in the prediction of failure rates and repair time distributions. The failure rate for each functional element can be recorded (see Fig. 3) and these can be combined to give the expected failure rates for different modes of operation of the equipment. The provision of a systematic fault-finding aid makes the estimation of diagnostic time more accurate because the sequence of tests needed to isolate each functional element (if defective) is determined objectively before the design is committed to hardware. The time for each test can be recorded and used with failure rates to calculate a mean time to repair. Thus the prediction of repair times can be much more worthwhile than it has been in the past when results have always been considered somewhat suspect due to the subjective nature of the method of evaluation. The application of D D S to the prediction of failure

Fault lies w i t h i n t h e ~ e p e n d e n c y s t r u c t u r e between t h e s e t w o events

Fault lies u p s t r e a m f r o m this event Go

ee Fault lies (3

(Last good indication)

'qF

~

w A v

NO-(IO (First bad indication)

No-go

Fig. 4.

36

COMPUTER AIDED DESIGN

I~1

[] 1

¢1

H

II II

b

I-'1~

o~ x

~ u,'i M

o~

Z

q

00

H~.

II

H,i

I~t~ ~, H~ I~1~ o

e

0

w

+1 cJ 0

i

I~1, \

,i

T

o l
\ \

~=~ -~y

Fig, 3. SUMMER 1970

37

rates and repair times in more de/tail than is usually done at present allows the maintainalSility of the equipment to be influenced. An indicator placed strategically may be shown to reduce diagnostic time very significantly. Alternatively functional elements on which many facilities depend can be identified and made more reliable, and a quantitative justification can be made for any increase in cost.

In particular the main requirements of maintainability can be continually monitored. These include making functional elements coincide with replaceable elements wherever possible, and placing external indications at the outputs of replaceable elements. The checking of these features from the dependency chart is a relatively simple and routine task. To summarise, the Development Documentation System gives a ready means of checking on the following: a. Interfaces and tolerancing. b. Failure rates and repair times. c. Design for maintainability. In addition it provides for the transfer of technical information in a standard format, continually updated throughout the project development, with the assistance this gives to writing handbooks, themselves an important maintenance tool.

Summary of Improvement to Manual Fault Finding Thus improvements in manual fault finding can be based upon the principles of isolating the signal flow, showing dependencies of elements along the signal flow and carefully specifying signals between each element. These principles applied to maintenance documentation in service result in FIMS, and when applied during development to improve design for maintainability result in DDS.

Automatic Test Equipment The first point about Automatic Test Equipment is that it has software just as a computer has. This is so, whether it is computer controlled or not. Furthermore the Automatic Test Equipment software has a hierarchy corresponding to computer software as follows: Machine code Actual instructions passed to the machine. Specific to one machine. Symbolic language Simple groups of machine orders, with neumonic titles. Specific to one machine. High level language Large groups of machine orders, user orientated, with English-like titles. Machine independent. Machine codes rapidly give place to symbolic languages, but high level languages with their compilers follow much more slowly. The major difficulty and expense in implementing A T E lies in the software. The existing test specification has to be made more rigorous, and often the test task has to be re-analysed. The result then has to be coded, using at best a symbolic language for a specific machine. The solution is to design the equipment and test specification with ATE in mind. But it is inconceivable that one specific test machine should dominate design. The machine obsolescence rate is quite as fast as the equipment obsolescence rate, and by the time the test was implemented, the test machine would have changed. In 38

any case the test machine may be different at different test locations, and standardisation to overcome this is quite impracticable.

High Level Test Language These difficulties can, however, be overcome by the use of a machine-independent high level test language, particularly if the language is readily understood by humans as well. In this case there is no commitment at design to any one test machine, or even to automatic testing at all. When automatic testing is decided upon, the paper tape containing the test specification could be compiled into a machine order code tape using an off-line computer and a special-to-machine compiler program. Such a high level test language does exist, produced by A R I N C in consultation with many test equipment designers, and users on both sides of the Atlantic. This language is called ATLAS. It would take too long to describe it in detail, but copies of the specification are available. However, an example of a series of Test statements is given here to show the general level of intelligibility. 75 M E A S U R E (TIME INTERVAL) $ 76 REMOVE, DC VOLTAGE, CNX HI J4-6 LO J4-8 $ 77 START W H E N , (VOLTAGE), DC SIGNAL, LT 0.5V, MAX T I M E 2 SEe, CNX HI J4-6 LO J4-8 $ 78 STOP W H E N , (FREQ), AC S I G N A L U K 18.2 MHz LL 18.2 MHz, MAX T I M E 5 SEC CNX HI J l - I LO JI-0 $ 79 C O M P A R E , ' M E A S U R E M E N T ' , LT 2.5 S E C $ 80 GO TO, STEP 45 I F N O G O $ 45 DISPLAY, MESSAGE, THE RX F A I L E D TO T U N E ON C H A N N E L 17 W I T H I N 2.5 SEC $ This program does contain a small number of abbreviations (known as 'pseudo-gibberish') but ' C N X ' is soon recognised as 'connection' and 'LT' and ' N O G O ' are almost standard computer jargon for 'less than' and 'no go'. When it is borne in mind that this program could be compiled automatically into machine code, the power of the language can begin to be appreciated. Several test equipment manufacturers plan to have limited compilers ready during 1970, though there are still problems associated with full ATLAS compilers.

Allocation of Test Points Not only is test software a problem in implementing ATE, but the allocation of test points at the design stage is perhaps even more important. This is the second feature of Automatic Test Equipment to be emphasised, and it is here that the maintainability aids already mentioned interact with the ATE approach. Dependency charts are very useful in assisting in the allocation of test points and test sequences, because they lead the designer to consider a test strategy during design. Equally, if the use of a high level test language were to be generally agreed, it should be used for all the test data on maintenance dependency charts. An American military specification already exists for the allocation of test points by dependency charts. There would be some advantages in combining a similar British document with the A T L A S specification to form a British standard specification for allocating and producing test data which could be read by man or machine. Such COMPUTER AIDED DESIGN

= Production Computer-aidedI organisation

developments, however, must await the more general acceptance of both the dependency chart and the high level test language.

layout programs

; I

S u m m a r y of ATE D e v e l o p m e n t s The economic implementation of A T E is currently seen to depend upon reducing software costs and increasing flexibility by enabling the test specification to be used directly as source material for producing the test machine code program. This requires the use of dependency charts for test point allocation and a high level test language for writing the test data. A T L A S is one such language, and investigations into its suitability are proceeding.

C o m p u t e r - a i d e d F I M S , D D S and A T L A S The aids to maintainability described so far can be produced manually for manual design. They have been described in some detail to show that they are real concepts which can be applied to improve maintainability. To be fully effective, however, they need to be produced with computer assistance, and finally integrated into the computer-aided design concept. The main features of F I M S are its hierarchy, the block diagram, the block text and the maintenance dependency chart. Computer graphics techniques could clearly give assistance in drawing block diagrams and block text in similar shaped blocks, and this would save a great deal of time. Furthermore, the maintenance dependency chart is related by an algorithm to the block diagram. Thus a computer can be programmed to draw maintenance dependency charts from the block diagram, so that any change in one will affect the other appropriately. In addition, the elements of the hierarchy can be made to depend on each other so that consistency can be maintained, at all levels, such features as the names and tallies of connectors and replaceable units. These details absorb a great deal of time when FIMS is produced manually. Computer-aided F I M S documentation offers a way of overcoming the handbook illustrator bottleneck and of producing timely DDS documents with consequent improvement in design for maintainability. Work along these lines is in hand. Furthermore, since a high level test language has a precise and limited vocabulary, and a clear and simple syntax, it can potentially be written by a computer as well as read by one. Thus generation of test data (in a form suitable for automatic or manual use) can, in principle, be carried out by the machine.

C o m p u t e r - A i d e d Design Systems Computer-aided design systems as they exist at present consist of a series of programs for analysis and simulation, which are the aids to circuit design, together with layout programs, consisting of programs to locate components on printed circuit boards, allocate board positions in the cabinet and design the back wiring runs. The linking of these design and layout programs is starting in the first computer-aided design systems. To make the system fully effective in the future, and to include the maintainer in the design process, two more sets of programs are needed as shown in Fig. 5. These are documentation programs, as discussed in paragraph 32, and a new set of Test Specification Programs. The future design system in Fig. 5 needs to be studied in slightly more detail. The Documentation Programs could be used to input data for the Design Programs.

SUMMER 1970

Computer- aided~ f t e s t spec.

r

Designer

Fig. 5.

documentation

[

~-

programs Maintenance (D D S ) I organisation

I

When a circuit has been evolved and checked by Design Programs, using analysis and simulation techniques, the block diagrams and dependency charts are available in the Documentation Programs, and could be displayed, using computer graphics, for the human assisted allocation of test points, test parameters and test sequences. The values of these parameters could then be generated by the simulation programs, with tolerances, and used as raw material for the Test Specification Programs. At the same time the circuit configuration could be used by the Layout Programs. These could, in addition, generate terminal identification code names and insulation and continuity checks, which are also needed as raw material for the Test Specification Programs. With these data, and some human intervention, again via the graphics terminal, the Test Specifications could be generated, using a high level test language, which would then be available for use by either humans or by automatic test equipment. In the last stages of the process the terminal names, components lists and layout diagrams could be fed into the Documentation Programs from the Layout Programs, while the test data was inserted in the correct place from the Test Specification Programs. Much work remains to be done before a human/ computer design system of this sort could be realised. However, its throughput would be many times faster than the current manual process and the product would have greater reliability and maintainability if only due to the provision to test data and documentation on time, without so many human errors. The ability to tie all these programs together involves, in essence, a Design System Computer Language, apart from quantities of hardware. A typical language which could do the sort of thing which is required is being developed by Racal Ltd., and is called Circuit Calculating Language (CCL). Its aim is to knit the various separate programs used in computer-aided design into a system, without having to re-enter each new program from the outside world, possibly with a different data format in each case. The work planned for computer assisted F I M S / DDS will also take into account the necessity to interface with CCL. Leaving the future, with its potential developments, consider for a moment the present and some of the developments in between. No change is instantaneous, and any system for design for maintainability must be applicable over the whole field shown on the table in Fig. 6. It must deal with the well established manual design, docu-

39

DEVELOPMENTS IN THE DESIGNER/~AINTAINER INTERFACE Documentation Design

Production

Test Execution

MANUAL

Well established

Well established

Well established

COMPUTERAIDED

Current

Nil

Current

AUTOMATIC

Beginning

Nil

Current

Fig. 6. mentation, and test methods as well as extend over the current developments of computer-aided design and automatic test equipments into the future areas of automatic design systems which have been discussed. Thus the computer-aided Documentation and Test Specification Programs to be developed must be capable of running alone, or in association with a design language in an integrated system. Furthermore, the test and documentation systems which these computer programs produce must be equally capable of production and use by humans. The system described in the earlier part of this paper has just this quality of flexibility.

Summary of Requirements What is required is a system, based on general principles which allows a single format to cross the following boundaries:

a. the development--in service boundary b. the hardware--software boundary c. the designer--maintainer boundary d. the designer--producer boundary e. the manual--automatic design and test boundaries Such a system could form a standard for designers to work to and for producers and maintainers to work from, while having sufficient growth potential to permit the exploitation of automation to the full. The F I M S / D D S / A T L A S system discussed in this paper may not fulfil all these conditions to perfection. It is sufficiently good, however, to form a sound basis on which to build and study computer-aided documentation and test specification programs for integrated computer-aided design systems. Conclusion Computer-aided design systems at present aim to link designer and producer. They do not aim to link designer and maintainer. This is due to the lack of a standard interface between designer and maintainer. A standard design-maintenance interface must cover manual procedures. In addition it must not inhibit but must encourage automatic procedures. The F I M S / D D S / A T L A S system described in this paper goes a long way towards meeting the requirements of a standard interface. Unless the designer-maintainer gap is bridged, the full potential of computer-aided design will not be realised. Received March 1970

H. W. Young, M.A., was educated at Durham School and Emmanuel College, Cambridge, graduating in 1950. Appointments in the Royal Navy have included work on gun fire control systems, a post-graduate course at the Royal Military College of Science, trials on an air-to-air guided weapon, and participating in the design of ship computerised action information systems. He is currently engaged in work on support and maintenance ~olicies for all Naval Surface Weapons Equipment.

40

COMPUTER AIDED DESIGN