Design and evaluation of experiments for the identification of physical systems

ARCHIEF

MASSACHUSETTS INSTITUTE OF TECENOLOGY

Department of Naval Architecture and Marine Engineering

Report No. 69-1

Design and Evaluation of Experiments for the Identification of Physical Systems

by

Michael Schmiechen

Prepared under

M.I.T. Contract No. DSP. 29132 M.I.T. Contract No. DSR 70042

Sponsored by

Max Rade Foundation, New York M.I.T. Instrumentation Laboratory

Lab. y.

Scheepsbouwkuflde

Technische Hogeschool

Deift

Desiqn and Evaluation of Experiments for the Identification of Physical Systems

by

Michael Schmiechen

AB ST RACT

The efficient design and evaluation of experiments for the identification of physical systems is strongly hampered by the lack of an adequate operational organization and implementation of the related methods and procedures. In order to improve this situation the development of an integrated system of simulation and estimation languages has been attempted, which may serve as a tool in the computer aided design and evaluation of experiments and eventually as a pattern for further developments. Starting from the conception of the design procedure in general and the development of an estimator in particular as multilevel adaptive feedback processes the major effort of the present work is

directed towards the identification of problems and the recogni-tion of patterns.

TABLE OF CONTENTS PAGE 1. Introduction 9 1.1 Orientation g 1.2 Organization _io 1.3 Motivation 11 1.4 Languages ₁₃ 1.5 Interpretations 14 1.6 Property Concept 15 2. Model Structure ₁₇ 2.1 System Concept ₁₇ 2.2 Overall System _i 2.3 Constraints ₂₀ 2.4 Specifications ₂₁ 2.5 Appreciation ₂₃ 3. Identification ₂₅ 3.1 Transformation ₂₅ 3.2 Measurement ₂₆ 3.3 Calibration ₂₈ 3.4 Deterministic Processes ₂₈ 3.5 Linear Systems ₂₉

PAGE 4. Estimation 31 4.1 Differential Systems 31 4.2 Orthogonality Principle 32 4.3 Sample Theory 33 4.4 Reference Functions 34 4.5 Numerical Procedure 36 4.6 Confidence Ranges 38 5. Implementation 40 5.1 Requirements 40 5.2 Language 40 5.3 Organization 42 5.4 Operation 43 5.5 Perspectives 44 6. Programming 46 6.1 General Procedure 46 6.2 Space Allocation 47 6.3 Simulation 48 6.4 Estimation 50 6.5 Further Tasks 52 7. Conclusion 54 7.1 Past 54 7.2 Present 55 7.3 Future 55

PAGE 8. Appendices ₅₇ 8.1 Symbols ₅₇ 8.2 Figures ₆₄ 8.3 System Decks ₆₉ 8.4 Programs ₈₃ 8.5 References 87 8.6 Acknowledgments 91

1.

iNTRODUCTION

i Orientation

The identification of physical systems, i.e., the determina-tion of their relevant properties from observed values of their terminal variables is one of the basic scientific and engineering problems, and the design of experiments is the first step

towards its solution, providing not only test programs but at the same time model sample data änd, last but not least, esti-mators for the evaluation of the experiments Fig. 1.

As any design the design of experiments may be conceived as a self-organizing multilevel adaptive feedback process. Experiments are simulated with a physical model adapted to the system to be identified and its environment and analyzed according to a procedure adapted to the model, while the test _program

is finally adapted to the integrated simulation and estimation system and thus hopefully serves its purpose, i.e., further adaptation of the abstract model to the physical system to be identified.

In view of this operational pattern the solution of a

design problem may be approached in four steps:

development of a model adapted to the _{system to be} identified and its environment,

development of a simulator adapted to the model, development of an estimator adapted to the _simulator and the actual system,

4. development of a test program adapted to the inte-grated simulation and estimation system.

However simple and straightforward this approach may appear, its realization involves considerable effort not

leastdue to the lack of an operational organization and imple-mentation of the related methods and procedures. This work is concentrating on the third step of the solution scheme, the development of estimators, while models, simulators, and test programs are considered only as far as they are of interest

in this context.

In fact, in the development of large systems,simulators are developed for various purposes and may often be considered

as available (Broxrneyer et al.., 1967).

1.2 Organization

The development of an estimator adapted to a model or rather its simulator is itself a self-organizing multilevel adaptation process. At the present time the human designer has to carry out all the adaptive functions, i.e., pattern recognition, decision, and modification including modifications of the pro-cedure itself.

In the present investigation the following organization for the solution evolved:

1. development of a model structure adapted to the model of the system to be identified and its environment,

development of a conceptual solution of the identi-fication problem adapted to the model structure, development of an estimation theory adapted to the model structure,

development of an operational implementation of the estimation procedure,

development of the actual estimator adapted to the model.

This report covers the present state of the solution _and furtherproblems identified rather than the history of its

development, the guiding principles of which were adequacy and consistency in a very wide sense, although the problem so

far was feasibility and not optimality.

The adaptation of the operational approach is itself of course the result of an adaptation process. _{The attempts to} apply the methods developed in a preliminary research _proqram for the identification of linear systems, _{(Oelmann, 1966-7),} in a wider context were doomed to fail, while _{the direct general} approach followed here proved to be conceptually, and computa-tionally, more easy to handle and at the same time apolicable to realistic models (Bellman, 1968).

1.3 Motivation

The original problem of the present investigation _{was the} identification of the maneuvering qualities _{of marine vehicles,}

whatever this means. In the light of the approach outlined in the previous sections reference to the mechanics of

marine vehicles is necessary only as far as the abstract models are concerned; even with the future advent of self-organizing models (Fogel, 1966) this will be necessary in

view of the higher level model adaptation process. The design procedure is essentially independent of the particular type of

system to be identified.

This method of imbedding a problem in a more general problem

(Polya, 1957; Bellman, 1968) is widely used on various levels

of the present approach. In fact, this introduction is an attempt to inthed the identification problem in the problem of the theory of knowledge thus not only setting the scene but Serving the explication of the problem and the recognition of methodical patterns.

Philosophical and methodical problems of this type are scarcely recognized and explicitly discussed in the technical literature and the implications concerning these questions are usually disguised by jargon and mathematical details, although a clear account, i.e., the identification of the logical and factual implications of the procedures adapted may be considered as vital for the teaching, research, and development processes and may eventually facilitate the exchange of methods between

various fields of application.

1.4 Languages

The conception of design and development processes as self-organizing multilevel adaptation processes may be considered as the result of an identification process on the highest level, i.e., essentially a self-identification process, which was part of the present effort. _{Due to the complexity of the object,} the patterns that evolved so far on this level are of course still lacking the ultimate clarity.

It appears as if each level of the adaptive _processes corresponds to a conceptual level or system, each of _{which has} to be expressed in a language of its own. _{A serious problem} arises now due to the fact that all the languages _{of interest in} a given context are so closely interrelated, that the necessary

distinction between them becomes very difficult in practice. The communication language used in this _{report as in others} switches freely between conceptual systems without _explicitly indicating so. This generic use of words is of _{course a matter} of conciseness and the reason for permanent _{inspiration and}

confusion (Carnap, 1959).

In order to achieve the final adequacy and _consistency, the system of languages has not only to be _{formalized, i.e.,} essentially axiomatized, but at the _{same time to be symbolized.} The notations are required to be concise _{and operational,}

particularly in view of direct implementations in terms of programing languages or, more general, realization languages,

1.5 and 5. In "conscious" development processes such notations evolve by necessity in permanent updating processes (Schmiechen,

1964)

While the advantages of the Arabic notion for numbers is universally appreciated, the far greater advantages of higher

level operational notations is hardly recognized. In principle, a problem formulation in an adequate notation will already

indicate possible procedures for formal solutions (Polya, 1957).

1.5 Interpretations

In science and engineering conceptual systems or rather their linguistic representations are not studied as such but as abstract models of physical or organizational systems or processes.

In this sense formal languages may simply be considered as problem oriented languages allowing direct problem formulation and after an interpretation in terms of a realization language

direct implementation, often simulation of the processes described, i.e., the correspondence rules are in this case implementation

or simulation rules.

Only in simple cases this interpretation and implementation may be automated. Particularly convenient are problem oriented

digital computers. Depending on the state of the development they represent more or less elementary operational implementations

of the state of the art in a field.

For research and development purposes systems of programing languages may conveniently be developed ad hoc; 5. The problems involved are primarily organizational not only concerning the programs, but even more concerning the data; 5. (Roos, 1966;

Schrader, 1968).

If formal languages are considered as formal parts of

dual theories and. interpreted in terms of observation languages the correspondence rules are identification or estimation

rules, relating the basic concepts or rather terms of the theories to observed variables; 3. and 4.

1.6 Property Concept

The basic concepts, the identification of which is the

objective of the present work, have been called properties;

1.1 In terms of the concepts introduced so far the properties of a physical system may now be specified as _{an abstract model} of the system or rather its format and parameters. _Properties are not necessarily attached to substances but may be purely operational in the contexts of formal languages (Leinfellner, 1965)

In the context of an established model format it is con-venient to refer to the parameters alone _{as properties. These}

are in most cases denoted by matrices, so that reference to this fact in the name of the property is not necessary, while components, which may themselves be denoted by matrices,

need specification. In general, components as such are of little importance, the essential roles in the formal languages play the invariants of the properties.

This leads directly to the conception of properties of physical systems as invariants in a very general sense. Reference to the theorems of group theory will by necessity become common practice in this context, particularly in view

of the creation of models consistent with the principles (Truesdell, 1966).

2.. MODEL STRUCTURE 2.1 System Concept

Following the scheme described in the introduction, 1.2, the model structure of the system to be identified _{and the} systems of its environment are required to be _{as general as} necessary for a wide range of applications and independent of particular conceptual systems.

In order to satisfy these requirements the black box

model is adopted. _{Parts of the terminal variables of a system} are considered as inputs and denoted by i,j,.., and _{one part}

as butput and denoted by o, any one of which

h = i ,j ,. .

may be a multidimensional function

h=h

(t)

uy..

of the time, denoted by t, and _{u,v,.. denoting operational} indices (Schmiechen, 1964)

it is now assumed that the Output of _{a system at any time t} is uniquely determined by that time, _{the state of the system} at a time t0 prior to t, and the inputs _{in the time range}

t' _{= (t0+tft+tf).} where tf denotes a finite anticipation.

In terms of the formal input-output-state _relation

(Zadeh, 1963)

the functional m is the abstract model of the system, its invariant property.

In particular it will be assumed here that the system is time invariant, i.e., that the above relation is invariant under translations of the time, and that the system has finite memory, denoted by th? i.e., that the output depends only on the inputs in the finite time range

t' ₌ (tt, t+tf)I

implying that the system is operated only in the range of one stable state

s (t0) const : t0 < t_th

As a result the input-output relation

0(t) = m(i(t'), j(t'),...) will be used.

However "natural the assumption of finite memory may appear at first

glance, for

nonlinear systems in general it is hardly reasonable. In order to retain the simple input-output

relation in the general case the original time range and a standard initial state

s(t0) = s0

have to be adopted. Further on it willbe assumed that the output is identical with the state

2.2 Overall System

The system to he identified will in practice neve: he

isolated, but tied up in an environment, of which the following overall model structure may be conceived Fiq. 2.

The system to be identified, system i in a feedback loop, is subject to the output of the control, system 2 in the ioop, and noise, for short

01 m1(i11j1)

with

ii = 02 and

ji = fl1 while the output of system 2

02 = m2 (i2,j2,k2)

is due to the output of the first system

'2 =

noise

= n2,

and guidance

k2 = g.

The outputs of the measuring systems, systems _{3 and 4} attached to the ioop,

03 = m3(i31j3) and

04 = m4(i4,j4)

are not only due to the outputs of the plant and the control

i3 _{= 02}

and

14 = 0,

but are also influenced by noise processes

i3 n3

and

i4 = n4 respectively.

All the processes involved are to be considered as stochastic, denoted as such by h.

2.3 Constraints

If the noise processes are essentially unknown there exists principally no possibility to identify functionals of the type suggested by the basic model structure. In order to resolve this fundamental difficulty the systems' transfer properties concerning the noise processes have to specified

apriori. The most convenient way to do this in a very general fa±ii is to consider the noise processes as added to the first

inputs.

The resulting modified model structure, Fig. 3, as directly derived from the basic model structure, Fig. 2, may be described

by the following set of equations: 01 = m1(i1) = °2 + = m2(i2,j2) = 01 + n2 = g 03 = m3(i3) 13 = + n3 04 m4(i4) 14 _{= 01 + n4}

In terms of this model structure the identification problem may be stated as follows. _{To be determined is the} model m1 invariant with respect to the driving _processes

g and n and the models m2, m3, and m4. _{Known are the inputs} j2 = g, the outputs 03 and 04? and the models m3 and m4, while everything else is essentially unknown. _{Explication of this}

statement will

lead to further specifications and _{a solution} of this problem.

2.4 _{Specifications}

In view of practical computations it _{may further on be} assumed that any one of the processes

may be described in terms of its format and its multidimen-sional parameter

h' i.e., in the form

h(t) ₌

The components of the parameters may be sample points of the processes themselves, their spectra, or any transform, or may be any other convenient measures of the processes.

In terms of the parameters introduced the original input-output relation reduces to the function

Po = m(p.,p.,...),

where the functor m is now the model of the system, its

invariant property. If in addition the models are expressed by their formats f and their parameters p , 1.6, the form

m m

Po = is obtained.

As all the processes h are considered as stochastic, 2.2, the parameters

h' but not those of the models, have to be considered as random variables and where necessary denoted as

such, They are in the present context conveniently specified

by their (joint) conditional probability densities with respect to the parameter of the driving process

While the densities d and d4(PO41P2) are

in principle known as results of measurements the densities of the noise processes n are principally unknown, but may be

assumed to be independent of the driving process: d (p

Ip

) = d (p ),

n n

j2

n n

and conditionally independent of the other processes

dm1 _n' 2)

= dh

hj2

dn _n

flue to the feedback incorporated in the model structure unconditional independence may not be assumed.

2.5 Appreciation

The incorporation of the feedback into the model structure is a direct consequence of the principle of adequacy. Most

systems to be identified are actually incorporated in a feedback loop and even for test purposes it is often impossible to open this loop, i.e., with unstable systems or in cases where the noise processes would lead to undesirable or even dangerous situatìons. Due to control the density functions are rather peaked, which is of advantage for the identification, despite

the extra difficulty introduced; 3.5. Any functional or function

m (...)

= f

(p

,...)

1 ml ml

solving the problem posed in the preceding sections in the range of interest may be considered as the system property looked

for. As a matter of economy only the simplest appropriate form of some convenient standard or canonical set _of func-Lionals or functions adapted to the system to be identified

is of interest. Functional polynomials (Volterra, 19597 Wiener, 19587 Lee, 19657 Barrett, 1963-64) or ordinary

poiy-nomials will in general not meet this requirement of economy. The assumptions made so far and further on are hypotheses about the system to be identified, its environment, and the processes involved, and these hypotheses have to be tested in a properly conducted identification procedure. As a matter of fact, this ultimate goal has not been approached in the present work. The test procedures are to be considered as format

identification procedures and are most important for the model adaptation process.

IDENTIFICATION

3.1 Transformation

In terms of the model structure established and the specifications added the identification problem may now be stated precisely as follows. The model m1 of the system to be identified has to be expressed in terms of the (conditional) output densities d_o3 and d_o4 and the inverse models m - and

3

of the measuring systems.

The two types of problems encountered in the solution of this problem may be distinguished immediately:

the measurement problem, which is essentially _a trans-formation problem, i.e., the determination of the input and output densities d. and d respectively

il ol

of the system to be identified from the known _output densities and inverse models of the measuring systems,

the actual identification problem, which is _identical with the calibration problem, i.e., the _{determination} of the model m1 from its input and _{output densities} as determined in the preceding step.

The basic transformation problem may readily be solved by reference to the definition of the probability _densities.

Assuming that the function p0 = m(p.)

has n values and introducing the Jacobian

J(m,p) = det (dm

(p )/d Po)

the transformation formula n

d. (p1) =) d (p

)/ jJ(m-1

_'k'

k= i

is obtained7 (Papoulis, 1965). If the model function m

has only one value as will be assumed further on in accordance with former assumptions, 2.1, this reduces to

d.(p.) = d (p)/J(m,p)I

for short

â. = d/G(m).

3.2 Measurement

The basic transformation rule derived applies in parti-cular to the measuring systems 3 and 4 so that as the first

step towards the solution of the measuring problem â. = â /G(m _1) o3 3 and

= d4/G(m4)

may be stated.

In order to determine the input and output densities â.4 and d1 the transformation of densities through summing systems under the influence of the noise processes has to be

applying the transformation rule to the relations 'k = 01 +

nlç= nk,

results in the equation

d.

=d

iknk olnk

As a consequence of the basic _{assumption about the} con-ditional independence of the noise _{processes and the other} processes this equation reduces to

d. = d

1k ok

for summing systems.

This is apparently the most _{essential step in any reasoning} of this type. _{It is only through the reference}

to an indepen-dent driving process that the effects of the essentially

unknown noise processes _{may be filtered out (Solodovnikov, 1965).} For the model at hand the following _{equations may now be} derived, d.

=d

=d.

il o2 and and d

_=d.

ol i4

which introduced into the _{former results lead to the solution} d. = d /G(m

11 o3

=

_d4/G(m41)

3.3 _Calibration

The second problem now, the identification problem _proper or the calibration problem may be characterized _{as follows.} The input and output densities

d.1 _{= d.i(p.iIp.2)}

and

= d1(p1Ip.2)

are together nothing else but an implicit _parameter represen-tation of the function

Pol = m1(p.1) to be determined.

The problem is solved if the parameter _{of the driving} process is eliminated under observation of the relation

d

=d./G(m).

ol ii i

Apparently there are no general rules how to achieve _{such a} solution.

ThOugh the model m1 determined in this fashion is in principle independent of the driving _{process and the control} model m2 as required the range explored does certainly depend on these functions.

3.4 Deterministic Processes

In the ideal case no noise processes are involved, so that the joint conditional density functions _{degenerate to}

generalized functions of the type of the Dirac function (Lighthill, 1964) and the deterministic description of the input and output processes in terms of functions

=

become s appropriate.

The measuring problem in this case has the solution

-1

= m3 (p03)

and

-1

Pol = ffl4 _(p04),

which is an explicit parameter representation of the function p1 = m1(p.1).

The elimination of the parameter of the _{driving process in} this case appears, at least in principle, _{to be simpler than} in the general case.

3.5 Linear Systems

If the system to be identified and the measuring systems are linear the same deterministic description as derived in the preceding section applies in terms of the conditional

expected values of the parameters. _{The reason for this is the} invariance of the expectation under _{linear transformations.}

For nonlinear systems this is apparently not the _case, but the relations between the expected values of the parameters

models. _{This approxiation will be the better, the narrower} the density functions, i.e., the better the local linear approximation of the model 2.5.

However useful the description of the stochastic processes in terms of finite dimensional random parameters may be for actual computations, at least in the cases of deterministic processes and linear systems it appears theoretically

inade-quate. An extension of the descriptive pattern to parameters of infinite dimensions, i.e., continuous parameters would have

4.

ESTIMATION

4.1 _{Differential Systems}

While explicit input-output (i.e., _{state, 2.1) relations} offer particular theoretical advantages _{as, e.g., in the}

conceptual solution of the identification _{problem, 3.,} recursive relations are _{more easily handled in actual} com-putations as, e.g., in estimation, _{4., and simulation, 5.}

In practice, very important are the continuous or differ-ential systems, the input-output relation of which may be rendered in the canonical differential _equation

cT(t) = m(o(t), i(t),i(t),...), (Zadeh, 1963), for short

m(o,ô,i,i,...) =O (4.2).

In the following development of _{an estimation procedure} the particular model structure

f (t) + f (t)p = O

O u u

with the functions

f0(t) = f00(t) + f0 _{(t)ò (t)} and

f (t) = f (t) + f _{(t)ô (t)}

u uO uy y

evolved for this type of _{system. The component functions} f., are in general nonlinear

functions of the output, the input, and its rates:

f..(t) = f..(o(t), i(t), i(t),...).

This structure, which is linear in trie output rate and the parameter, is convenient for simulation and estimation at the same time and covers a wide range of practical models.

Concerning the measuring systems it appears appropriate in this context to assume that their outputs are continuous estimates of the magnitudes to be measured, i.e.,

23 ₌

Ii

and

as may be necessary, e.g., for control purposes; (Broxmeyer, 1969).

4.2 Orthogonality Principle

In terms of the concepts introduced an error process =

may be defined, the best mean square estimate of which is its conditional expectation in terms of the driving process:

=

(Papoulis, 1965).

It will now be assumed that the error process is indepen-dent of the driving process, i.e.,

and that the expectation of the error process vanishes, i.e.,

E(e1) = O.

As a consequence of the assumptions any functions of the two independent processes are not only independent but even

orthogonal, in particular,

E(f9(j2)e1) =

This so-called orthogonality principle (Deutsch, 19657 Papoulis, 1965), together with a model structure, e.g.,

fmiml'24'2413'°3?"J = O

is the basis of the so-called parameter estimation. _{For the} particular model structure described in the preceding section the estimation problem may be rendered in the form of the linear equation

+

(ff

) p = O

-U-_V y u

4.3 Sample Theory

In practice not the stochastic processes themselves are

available, i.e., their complete statistics as, e.g., required in the conceptual solution of the identification problem, _3., but only samples of them, in particular, sample points of single members of the processes. _{Under the assumption of ergodicity} with respect to the relevant statistical _{properties the} ortho-gonality principle may be rendered in the form

) f

₂ (t)) e (t) = O V for short fg e = O uy y u

For the particular model structure

e =t

+f

D

y 0v

wvw

this results in the linear estimation equation

fgf

fg

_f

_{p =0}

uvOv

UV WV W U

The assumption of ergodicity is again a hypothesis the test of which should be part of a proper estimation procedure.

4.4 Reference Functions

So far the set of reference functions fg has not been

u

specified. The very convenient orthogonal set

f = J (y ) exp (iv t)

u 2 u u

where J2 is the Fourier spectrum of the driving process j2 and y is the circular frequency, leads to difficulties if nonlinear systems are to be identified.

*

With the conjugate spectra F of the functions f the

v,u y

estimation equation becomes

*

*

J F

+J

F

p =0

2u 0,u 2u v,u y u

and the application of Gauss' transformation leads back to a real problem:

R R

+R

R p O

ou vO vu

vw w

u

where

R = E(j_ (t-t ) f (t))

vw 2 _V -w

is the crosscorrelation of the driving process with the func-tions of the estimated processes.

Again under the assumption of ergodicity this may be

expressed by sample points of single members of the stochastic processes. In practice, the driving process is very often a

sequence of uncorrelated Dirac pulses. _{In this case the} cross-correlations are computationally easy to obtain.

But the whole procedure as developed at the Berlin Towing Tank (Oelmann, 1966-67) for linear systems may not be applied if non-linearities are to be identified. Due to the fact that vanishing correlation values do not by necessity imply functional independence, the application of the harmonic reference _function will in general lead to systematic errors.

In order to resolve this fundamental difficulty the refer-ence functions have to be determined from samples taken from a physical model, i.e., a simulation of the overall system driven by the same process j2 as the actual _{system but not by} noise processes.

Before the model can be set up a first approximate estimate of the system property p _{must be available. One way to}

obtain this estimate in the present context is to identify the reference functions fg with the function set f derived

u u

from the estimated input and output processes, i.e., to do as if the feedback loop was open:

fg=f

u u

In this case, which will further on be treated in this report, the estimation equation becomes identical with Gauss' normal equation. Whether the subsequent iteration

process, which serves essentially the elimination of systematic errors due to the feedback of noise, is asymptotically stable remains to be investigated. At the present stage of the work any effort in this direction was felt premature.

4.5 Numerical Procedure

Following the lines indicated the numerical problems to be solved in the first approximation are in sequence the deter-mination of the matrices

S

=f

f

=S

UW UV WV WV

and

S

=f

f

uO wv 0v

and the solution of the normal equation

S

p =-S

uw-w

uO

However straightforward ,this approach was discarded due to previous experiences with similar regression problems and the

rounding errors encountered, which are apparently the crux of the whole problem. In fact, the determination of the normal matrices may be completely avoided, if the problem is restated as follows. To be determined is the property p from the

equation

f

+f

p =e

Ou vu y u

so that the squared error is minimum:

2

e

e =e =min.

u u

Despite the large variety of procedures available for the solution of this problem, employing either finite-number-of-steps methods or search methods (Wilde, 1964), the problem is in any case delicate (Bellman, 1968).

For the purpose at hand a method of orthogonal descent or conjugate steepest descent has been adopted. _{The basic} features of this procedure may be described _{as follows. The} original problem is not solved directly but _{transformed to} the problem g

q =-f

vu y Ou with -1 q

=r

p y

vw w

where the transformation matrix r is triangular _{and built up} in the recursive Gram-Schmidt procedure (Zurmíhl, _{1957) such} that the functions g are orthonormal.

Consequently, the Gauss transformation leads to the degenerate normal equation

q =-g

f

U UV 0V

and the solution

p =r

q

u uy y

of the estimation problem.

4.6 Confidence Ranges

Apart from the tests of the various hypotheses the conf i-dence range of the property determined according to the proce-dure established is of particular interest.

This range has constant components c = t(e2/(n

for the normal property q, where t denotes Student's fractiles,

e.g.,

t95% = 1.96 + 2.44/(nF_l)

the number of samples, and nF the degrees of freedom. Due to rounding errors the squared error e2 has to be determined according to its definition. The shortcut

e2

=

-as a difference of large, nearly equal numbers, leads to erro-neous or even meaningless results.

norma.] property components the corresponding ranges for the actual property components are

½

c

_=c.(r

r

k ku ku

For limited sample sizes there _{may exist minimum} confi-dence ranges c for subsets of property _{components, i.e., the} complete, more sophisticated models _{are not necessarily "better"} as they may not with higher confidence be identified _{from limited} data as compared with simpler models. _{This fact, however}

evident it appears, must be _{considered as a fundamental}

5. IMPLEMENTATION

5.1 Requirements

The development of the operational implementation of the estimation procedure outlined was again guided by the principle of adequacy in a wide sense.

For test purposes an integrated system of simulation and estimation languages was required and the development started with the simulation system, as this did involve the least conceptual problems, but allowed ready implementation and observation of organizational possibilities and patterns.

During the adaptive process initiated decisions were made concerning the programming language, the program organization,

etc. The most important requirement turned out to be that of

flexibility, allowing rapid adaptation to evolving and changing procedures. The system that evolved so far is still experi-mental, rather a research than a production tool, with formats

and routines yet to be established.

Any final decisions as to the organization of the system whenever they were attempted were soon felt premature and restrictive.

5.2 Language

language is on the level of implementation. For the purpose at hand a high-level procedure-oriented language is required which is not only flexible as far as numerical algorithms are

concerned but even more important as far as data and file organization and input and output are concerned.

In particular an adequate richness in concepts adaptable to abstract notations is required. As close as possible to a natural language it should be applicable on all levels of the system and to a certain extent be documenting and self-explaining.

Due to these requirements the algorithmic languages ALGOL and FORTRAN were outruled right from the beginning. Intermediate attempts with an established simulation language (CSMP) _were largely hampered by the lack of adequate concepts _and flexibi-lity and in view of the final integration with the estimation system this language was discarded as well.

The only language at hand meeting the requirements _nearly ideally is PL/I, which has actually been designed _{to meet the} requirements established, and has already been _{used for the} programming of systems for reasois similar to those mentioned here (Corbato, 1968).

5.3 Organization

Basically the program system is required to allow ready changes of the models to be simulated and identified without the necessity of complete new programs to be written in any particular case.

The present system of programming languages does just meet this requirement on a very elementary level. A

rudimen-tary precompiler does in fact nothing but insert problem specific statements in the basic simulation and estimation source programs, which are then compiled, linked, and

executed.

Any elaboration on the precompiler as far as sorting, command interpretation, and related facilities are concerned was felt not only premature but even restrictive. At a later

stage the facilities may easily be incorporated, when and wherever felt appropriate in the evolutionary process.

Instead of inserting statements into a basic program on

the pseudocomrnand

>INSERT ....

utilizing a special precompiler, the use of the PL/I precom-piler, i.e., in particular, the compile time facilities

and

% INCLUDE

has been considered. As this would have resulted in additional coding on the level of the problem-oriented languages it was

discarded, as was the possibility to CALL PROCEDUR, the coding of which is even more involved.

The later technique in conjunction with the method adopted here and precompiled procedures may eventually be the most

efficient as far as compile time is concerned, but not neces-sarily in view of the execution time. At least in the devel-opment the compile time is not critical. It is in any case

cheaper than the time spent on elaborate coding.

5.4 Operation

The whole system has been implemented and run under the IBM System/ 360 operating system (IBM System/360 Operating System), partly utilizing catalogued job control procedures of

the M.I.T.

Information Processing Services Center.

During the development of the system its operation was broken down into eight jobs as documented in Appendix 8.3.

In the first two jobs LSTPROG and GENPROG, an auxiliary list and store program and the precompiler, the generation program, are catalogued and stored as load modules LST and GEN, respec-tively, on the data cell. In the two jobs DSSPROC and DSAPROC LST stores the basic different:ial system simulation and analysis

procedures as source decks on the data cell, while in the two jobs DSSPROG and DSAPROG the program GEN generates the simulation and analysis programs proper, which are again catalogued and

stored as load modules DSS and DSA, respectively. Finally, in the jobs DSSIML and DSANAL, the programs DSS and DSA are executed, the results of the simulation being stored on the data cell.

The complete listings of all jobs in Appendix 8.3 show all the job steps necessary for the operation as scratching of

files (SC), allocating new space (Ac), compiling of source decks (cP), linking of object decks (LK), etc. Wherever appropriate a list (and store) step (ST) has been included,

in order to obtain a full documentation for each job.

5.5 Perspectives

Further developments of the integrated system of program-ming languages will strongly depend as they did so far on the program development as described in the next chapter. Wherever routines evolve independent of the particular physical system

at hand they may be incorporated in the system programs and their organization.

The development of a more elaborate precompiler including sorting, command interpretation, and related facilities has

already been mentioned. In any case PL/I code should be admitted on the level of the problem-oriented languages in order to retain

flexibility for the expression of spontaneous ideas and essen-tially non-routine problems.

For convenience the data organization should be automated as far as adequate in view of the overall development of the

system. The final organization of the system may be conceived

as modular such that not only the models may be readily

changed, but also the integration procedures as already imple-mented in many simulation languages, and in particular the esti-mation procedures.

Again any effort in this direction would have been pre-mature and actually far beyond the aim of the present work.

An executive program completing the operational integra-tion of the system should be conceived in view of operaintegra-tion under a time-sharing system, i.e., in view of on-line opera-tion (Free, 1967). Due to the fact that, up to the present, PL/I is not yet supported by the M.I.T. Compatible Time-Sharing System, the corresponding development, however promising it appeared, could not be initiated. The advantages of PL/I far outweigh the drawbacks and the frustration experienced in batch-processing until, hopefully in the not too far distant

6. PROGRAMMING

6.1 General Procedure

Basic for the efficient direct application of the exis-ting programming system is the full appreciation of the source programs representing the simulation and identification

algorithms adopted and the job control programs, in particular the data definitions (DD) providing appropriate allocation of

space.

For the sake of uniformity the problem statements for both programs have to be arranged each in ten groups under the same headings, which have to begin in the first column of a punched

card, while the PL/I statements have to begin not before the second column (and end in the 72. column) under the default format option of the compiler. The headings in the dummy

code and in the examples in Appendices 8.3 and 8.4, respectively, are suggested by the basic programs and indicate roughly the types of statements to be inserted. Actually these headings may be arbitrary and abbreviated to a single character (except / (slash)) in the first column, except for PROB and DATA.

If additional >INSERT commands are introduced the problem code has to contain the matching number of headings in the appropriate order.

With the present simple-minded version of the precompiler all the headings of a program have to appear in the problem code

even if the groups of statements they are heading are empty as shown in some instances in the examples in Appendix 8.4.

The examples show in particular the use of "global

parameter', _{i.e., identifiers already declared in the basic} programs, and of identifiers newly declared in the problem

statements. _{Declarations may be placed freely, but their range} is limited to the blocks in which they _{are occurring and the} blocks included, provided the identifiers are not redeclared. Accordingly, care has to be taken that no global identifier is redefined.

Due to the block structure of basic programs dynamic array declarations, i.e., object time allocation, has _{been and may} be freely used.

In listing the data the proper order of data requested by the basic programs and the problem codes _{has to be observed.}

6.2 Space Allocation

In order to avoid the adaptation of the data _definition parameters for every particular execution of _{the simulation}

and analysis modules DSS and DSA variable record formats have been applied. _{The maximum logical record lengths (LRECL) and} the number of allocated tracks (SPACE) _{may be adjusted to suit} the needs for a variety of problems.

For the files in question the following rules have to be observed:

sample data (SDATA):

1600 > LRECL > SDIMS (1) * SDIMS (2) * 8 + 4,

SPACE > (SINTvS + 1)/FLOOR (1600/LRECL),

original and orthonormal functions (ORFCTS, ONFCTS): 32000 > LRECL> FDIMS * (SINTvS+l) * 8 + 4,

SPACE> FCTS/(FLOOR (32000/LREcL), transformation matrix (ONMATR):

J32000

> LRECL> FCTS * S + 4,

SPACE> as before,

where double precision has been attributed throughout, s.6.4. In some future complex applications it may be desirable to save the original and the orthonormal function sets. Due to the limited record length on the data cell a rented disk may have to be chosen as secondary storage.

6.3 Simulation

In view of utmost flexibility in the simulation program only the inputs and outputs (states) of the systems have been

declared. In the two-dimensional matrix representation the

first dimension refers to the system, the second to the input or output dimension. The restriction of the input and output

is not severe, as the subdivision of the overall system to be simulated into section systems is pretty arbitrary and may be chosen to meet the requirements of the format implemented.

Except that all systems are assumed to be of the contin-uous or differential type no detailed model structure has been preestablished in general. Only the system to be identified will have to be of the simple structure

= OU + oo + vo

basic for the estimation procedure.

In the SYSTEMSEQUATIONS instead of the output (0) itself

its predicted, i.e., the extrapolated, value (0E) has to be inserted. _{This slight inconvenience reminds of the underlying} very simple-minded prediction-iteration procedure adopted for

integration, and may easily be changed. For ready use the first and second time derivatives or rates (OR, aRR) of the _output and their extrapolated values (ORE, ORRE) are available.

For a simulation the start time (STARTT), stop time (STOPT), time or integration step (TSTEP), and sample _{step (SSTEP)}

have to be specified. _{They may be changed, e.g., in a FINISH} procedure for consecutive runs. _{Actually the duration of the}

runs _{and the sample rate have to be adapted to the model and}

its environment and this adaptation is _{eventually one of the} main objectives of the design of experiments.

In order to facilitate experimentation with models of

the system to be identified the simulated control and measuring systems should be self-adaptive as far as possible. An

ade-quate simulation program should thus not only comprise noise and test program generators, but in addition, e.g., recursive filters for the estimation of state variables, a self-organizing multi-degree of freedom general-purpose control,etc.

6.4 Estimation

The estimation procedure has been described in detail in Chapter 4. The problem formulation in terms of the language developed, i.e., the basic program is straightforward. In the INITIALIZATION the function f0 (FO) has to be specified, while in the SYSTEMSEQUATIONS the function set f (FI) has to be

defined.

In the case of a homogeneous estimation equation one component (k) of the property p may arbitrarily put equal to unity and accordingly

f =f

o k

If one of the property components is zero by definition the corresponding condition (PCOND) component has to be put equal to unity; s. example 1 in Appendix 8.4. The condition code of the output has the following meaning

O: component properly identified, component zero by definition,

component zero due to linear dependence of data, component zero due to complete description of the

data by the components already identified. Numerical problems may arise for variables

the range of which is centered far off zero and largely exceeding

unity. The normalization may be considered part of the problem-oriented program. In view of nonlinear systems and the

prob-lems encountered in the inverse transformation, no general transformation scheme may be established.

The structure of the basic program restricts the system properties to those which may be represented by matrices of not more than three dimensions. A higher degree of flexibility may be desirable and achieved through the use of compile

time facilities.

The tests of the basic program with a simple linear model of the type

o =p

o +i

u uy y u

showed a rapidly increasing computation time with increasing number of dimensions of the system as was to be expected. Attempts to reduce this time by block transfer of data to and

and from the secondary storage devices did not show the

expected results.. Attempts to suppress zero multiplications

on a large scale showed similarly indecisive results.

In view of rounding errors all computations are carried out in double precision. In principle, only the inner products occurring at various stages of the procedure would have to be

accumulated in double precision before rounding (Rail, 1965).

6.5 Further Tasks

In view of particular fields of application, e.g., the mechanics of marine vehicles, the following developments may be envisaged. As experimentation with various models will become routine, e.g., in a higher level adaptive process, it will become necessary to develop algorithms for the creation of

models conforming to established principles, i.e., systems equations for simulation and estimation, i.e., essentially a higher-level problem-oriented language.

A simple way to do this in the context of the present pro-gramming system is to develop programs for the most complex

model and then utilize only submodels by defining the irrelevant parameters to be zero. Due to the fact that only certain typical

submodels of multidimensional systems are of interest, the

suppression of irrelevant parameters may be achieved by stating the relevant degrees of freedom.

Another type of problem, actually closely related to the former is that of handling prior information, especially

components estimated from the results of previous tests with

particularly designed test programs. This problem is essentially a problem of initialization. The estimation equation to be

solved is

unknown known

f _p -f

-f

_p

vu y Ou vu y

Extending the condition code, e.g., to -1 for components previously identified, the incorporation of these components is easily achieved. Actually this problem may be considered as so fundamental that the corresponding feature should be

included in the basic program. In view of this type of problem and the iterative estimation procedure outlined in 4, the

integrated simulation and estimation system will certainly have to operate under a time-sharing system.

7. CONCLUSIONS

7.1 Past

The development of an estimation procedure for nonlinear systems described in this report resulted in the implementation of an integrated system of simulation and estimation languages. The lack of an operational organization and implementation of the related standard methods and procedures was actually the main hindrance in the efficient design of experiments.

Frustra-tion of the same type has been experienced in other fields and led to corresponding systems' developments (Roas, 1966; Eisner,

1969).

In view of the ever-increasing complexity of the problems to be tackled, the operational organization of methods and procedures, of knowledge in general, becomes a matter of necessity not only for the application of computers but in the first instance for a better understanding and consequently identification of problems and further extension of knowledge.

Implementation in terms of computer programs, program

or programming systems adds ready availability, and this allows efficient experimentation and adaptation as, e.g., required in design and development processes as described (Widnall,

7.2 Present

The problems, perspectives, and tasks identified so far and listed in the appropriate chapters are essentially starting points for new cycles of the adaptive processes. The steps to be taken are clearly outlined in the appropriate chapters. Although the thoughts and ideas are in principle classical, the whole approach will hopefully serve a a pattern for further developments.

In any case, on any level the proper identifications of the problems proved to be the first and decisive steps towards their solutions. As outlined in the introduction, adequate languages and their proper distinction are prerequisites in this phase. Particular problems are due to the word language, which serves as epi- and metalanguage for the various formal

languages and tends to become an inadequate and confusing jargon. As mentioned, at the present stage all the adaptive func-tions are carried out by human designers. Correspondingly, the program organization and operation is required to integrate the designers as far as possible.

7.3 Future

So far the work presented is not the ultimate solution of a problem but rather a program and a suggestion how to proceed,

eventually towards an integrated system for the design of experiments.

Essential part of the evolutionary process will be, as it was, the level of adaptation, which starts with self-identification. Better understanding of the processes involved will lead to an improvement of the process, its further

objecti-vation, and automation.

Adequacy, the ultimate goal on all levels, is not a matter of elegance but rather of efficiency, whatever that means in the context of research, development, teaching and learning processes. In terms of problem-oriented programming languages abstraction does no longer exclude operation.

The tasks are challenging. Not only that conceptual solutions for complex and changing organization problems are to be established but at the same time their implementation in

terms of computer programs has to be developed. Another

challenge is the problem of education and training for future, yet unknown, requirements, i.e., essentially the efficient initialization of self-organizing systems under the aspect of an operational integration of artificial and human intelligence.

8. APPENDICES 8.1 Symbols

The symbols in this appendix are arranged in three groups; the first listing, the symbols of this report for magnitudes and indices together with the numbers of the sections of their

first occurrence and explanation, the last two listing the identifiers used in the basic simulation and estimation programs, respectively, together with their attributes.

8.1.1: Symbols of the report

8.1.2: Identifiers of DSSIML 8.1.3 Identifiers of DS?NAL

8.1.1 Symbols of the report

8.1.1.1. Magnitudes, Functions, etc. c 4.6 confidence ranges

d 2.4 probability densities

det 3.7 determinant e 4.2 error process

E 4.2 expectation

f 2.4 foiiiiats, structures, functions

F 4.4 spectra

g 2.2 guidance, test program g 4.5 orthonormal functions

8.1.1.1. (continued)

absolute values of Jacobians time functions

stochastic process

derivatives of time functions estimated time functions

inputs imaginary unit identity system inputs Jacobians spectra inputs models, properties noise processes numbers outputs parameters, properties orthonormal parameters transformation matrix correlations states G 3.7 h 2.1 h 2.2 4.1 4.1 i 2.7 i 4.4 I 8.2 j 2.7 J 3.7 J 4.4 2.1 m 2.7 n 2.2 n 4.6 o 2.7 p 2.4 q 4.5 r 4.5 R 4.4 s 2.7

8.1.1.1. (continued) S 4.5 normal matrices t,t' 2.2 time t 4.6 student's fractiles y 44 circular frequency future free samples reference history components system S 4.6 samples operational index ditto ditto initial system to be identified system in the feedback loop

measuring system for the system input measuring system for the system output

u 2.7 y 2.7 w 2.7 0 2.7 1 2.2 2 2.2 3 2.2 4 2.2 8.1.1.2. Indices f 2.7 F 4.6 g 4.2 h 2.1 k 4.6 1 2.2

8.1.2 Identifiers of DSSIML I IDI MS I DN INFILE IR IRR J JOB JOBS MAXCOMP MIDIM MODIM O ODIM ODIMS 0E OR O RD O RE O RM ORR inputs input dimensions identification no. input file

first input derivatives

second input deriva-t i ve s

inputs

job no.

number of jobs maximum component

maximum input dimension Maximum output dimension outputs

ouput dimension no. Number of output dimensions

outputs, extrapolated first output derivatives

output derivative deviations

first output deriva-tives, extrapolated output derivative memories

second output deriva-tives

(*,*), AUTOMATIC, DECIMAL, FLOAT (DOUBLE)

(*), AUTOMATIC, BINARY, FIXED (15,0)

AUTOMATIC, BINARY, FIXED (15,0) FILE, EXTERNAL, INPUT, STREAM

(*,*), AUTOMATIC, DECIMAL, FLOAT (DOUBLE) (*,*), AUTOMATIC, DECIMAL, FLOAT (DOUBLE) (*,*), AUTOMATIC, DECIMAL, FLOAT (DOUBLE)

AUTOMATIC, BINARY, FIXED (15,0) AUTOMATIC, BINARY, FIXED (15,0) ENTRY, BINARY, FIXED (15,0) AUTOMATIC, BINARY, FIXED (15,0 AUTOMATIC, BINARY, FIXED (15,0)

*), AUTOMATIC, DECIMAL, FLOAT (DOUBLE)

AUTOMATIC, BINARY, FIXED (15,0) (*), AUTOMATIC, BINARY, FIXED (15, 0)

(* *),

AUTOMATIC, DECIMAL, FLOAT (DOUBLE)

(*,*), AUTOMATIC, DECIMAL, FLOAT

DOUBLE)

(*,*), AUTOMATIC, DECIMAL, FLOAT (DOUBLE)

(*,*), AUTOMATIC, DECIMAL, FLOAT

(DOUBLE)

(*,*,*), AUTOMATIC, DECIMAL, FLOAT (DOUBLE)

(*,*), AUTOMATIC, DECIMAL, FLOAT (DOUBLE)

(* *), AUTOMATIC, DECIMAL, FLOAT

(DOUBLE)

(*,*), AUTOMATIC, DECIMAL, FLOAT

(DOUBLE)

FI LE, EXTERNAL, S T REAM

(*), AUTOMATIC, BINARY, FIXED (15,0) AUTOMATIC, BINARY, FIXED (15,0)

AUTOMATIC, BINARY, FIXED (15,0)

AUTOMATIC, DECIMAL, FLOAT (DOUBLE)

AUTOMATIC, DECIMAL, FLOAT (Dol:IBLE)

AUTOMATIC, DECIMAL, FLOAT (DOUBLE) GENERIC, BUILT-IN FUNCTION

AUTOMATIC, BINARY, FIXED (15,0) AUTOMATIC, BINARY, FIXED (15,0) AUTOMATIC, DECIMAL, FLOAT (DOUBLE) AUTOMATIC, BINARY, FIXED (15,0) AUTOMATIC, DECIMAL, FLOAT (DOUBLE) AUTOMATIC, BINARY, FIXED (15,0) AUTOMATIC, DECIMAL, FLOAT (DOUBLE)

AUTOMATIC, DECIMAL, FLOAT (DOUBLE) (*,*), AUTOMATIC, _{DECIMAL, FLOAT}

(DOUBLE)

(*,*), AUTOMATIC, DECIMAL, FLOAT

(DOUBLE)

AUTOMATIC, BINARY, FIXED (15,0) FILE, EXTERNAL, PRINT, STREAM AUTOMATIC, BINARY, SIXED (15,0) AUTOMATIC, BINARY, FIXED (15,0) AUTOMATIC, BINARY, FIXED .(15,0)

8.1.2 (continued)

O RRE second output deriva-tives, extrapolated OUTFILE output file

RS STEP relative sample step

RUN run no.

RUNS number of runs

S sample

S DATA sample file

SDIMS sample dimensions SINST sample instance no. SINTVS number of sample

intervals SS TE P sample step STARTT start time STOPT stop time

SUM sum

SYS T system no.

SYSTS number of systems

T IME time

TINST time instance TINTV time interval no.

TI NTVS nunther of time intervals TSTEP time step

8.1.3 Identifiers of DSANAL CONF confidence range

D deviations

DI deviations

8.1.3 (continued) DPR DQ FO FCTS FDIMS FI GI GJ I I DN

INFIE

I TE RT S J ONFCTS ONMATR O RFCT S OUTFILE p PCOND PCONF PDIMS deviation of the relevant parameters

deviation of the normal par ame te r s function f o number of functions number of function dimensions functions f orthonormal functions orthonormal functions counter identification no. input file number of iterations counter orthonormal functions transformation matrix original functions output file parameter (matrix) parameter condition parameter confidence range parameter dimensions

(*), AUTOMATIC, DECIMAL, FLOAT (DOUBLE)

(*), AUTOMATIC, DECIMAL, FLOAT (DOUBLE)

(*,*), AUTOMATIC, DECIMAL, FLOAT (DOUBLE)

AUTOMATIC, BINARY, FIXED (15,0) AUTOMATIC, BINARY, FIXED (15,0)

(*,*), AUTOMATIC, (DOUBLE) (*,*), AUTOMATIC, (DOUBLE) (*,*), AUTOMATIC, (DOUBLE) AUTOMATIC, BINARY, AUTOMATIC, BINARY, DECIMAL, FLOAT DECIMAL, FLOAT DECIMAL, FLOAT FIXED (15,0) FIXED (15,0) FILE, EXTERNAL, INPUT, STREAM AUTOMATIC, BINARY, FIXED (15,0) AUTOMATIC, BINARY, FIXED (15,0)

FILE, EXTERNAL, BUFFERED, SEQUENTIAL, RECORD

FILE, EXTERNAL, BUFFERED, SEQUENTIAL, RECORD

FILE, EXTERNAL, BUFFERED, SEQUENTIAL, RECORD

FILE, EXTERNAL, PRINT, STREAM (*,*,*), AUTOMATIC, DECIMAL, FLOAT (DOUBLE)

(* ,* ,*),

AUTOMATIC, BINARY, FIXED (15,0)

(*,*,*), AUTOMATIC, DECIMAL, FLOAT (DOUBLE)

(*,*), AUTOMATIC, BINARY, FIXED (15,0)

8.1..3 (continued) PR P Rl PRCONF PPD IM Q RI RJ RMS D S SD S DO SD1 S DATA SD IMS SI SINST SINTVS SJ T relevant parameter ditto, initial relevant parameter confidence range relevant parameter dimension normal parameter

column of the trans-formation matrix

ditto

root mean square deviation sample squared deviation ditto, initial ditto, intermediate sample file sample dimensions Rayleigh quotients sample instance no. number of sample intervals

Rayleigh quotient

Student' s fractiles

(*), AUTOMATIC, DECIMAL, FLOAT

(DOUBLE)

(*), AUTOMATIC, DECIMAL, FLOAT

(DOUBLE)

(*), AUTOMATIC, DECIMAL, FLOAT

(DOUBLE)

AUTOMATIC, BINARY, FIXED (15,0)

(*), AUTOMATIC, DECIMAL, FLOAT

(DOUBLE)

(*), AUTOMATIC, DECIMAL, FLOAT

(DOUBLE)

(*), AUTOMATIC, _{DECIMAL, FLOAT}

(DOUBLE)

AUTOMATIC, DECIMAL, FLOAT (DOUBLE) (*,*), AUTOMATIC, _{DECIMAL, FLOAT}

(DOUBLE)

AUTOMATIC, DECIMAL, FLOAT (DOUBLE) AUTOMATIC, DECIMAL, FLOAT (DOUBLE) AUTOMATIC, DECIMAL, FLOAT (DOUBLE) FILE, EXTERNAL, BUFFERED,

SEQUENTIAL, RECORD

(*), AUTOMATIC, BINARY, FIXED (15,0)

AUTOMATIC, DECIMAL, FLOAT (DOUBLE) AUTOMATIC, BINARY, FIXED (15,0) AUTOMATIC, BINARY, FIXED (15,0)

AUTOMATIC, DECIMAL, FLOAT (DOUBLE) AUTOMATIC, DECIMAL, FLOAT (DOUBLE)

8.2 Figures

The figures in this appendix show the models of the

identification system including the design system as described in section 1.1, the model structure of the physical system to be identified and its environment, as described in sections 2.2 and 2.3, and the model of the summing system as referred to in section 3.2.

Fig. 1: Model of the identification system,

Fig. 2: Basic model structure of the physical system to be identified and its environment,

Fig. 3: Modified model structure of the physical system to be identified and its environment,

Fig. 4: Model of a summing system with auxiliary identity system.

Model of System to be ident. a..its env Model of system to _{be ident.}

Property

Simulator implement and adapt Estimator implement and adapt

Model of the design system

Estimator Program design a. adaptat.

Model

sample da t a

Simulator

3

Fig. 1:

Model of the identification

system. Test program of system Sample Estimator Mo n i t or to be id. data

Input measuring system --il -13 °2 Feedback s y s tern m2 n3 g n2 Fig. 2:

Basic model structure of the physical

system to be

identified and its environment.

'2 System to be identified 01 14 Output measuring system 04 m4 m3 o

03 Input measuring system m 3 n3 + Feedback system nl

_1i2

F

System to be identified 01 -m -1 ₊ + 14 Fig. 3:

Modified model structure of

the physical system to be

identified and its environment.

Output measuring

ystem

o 4

+

il

I

I

01

1

Fig. 4:

Model of a summing system with auxiliary identity system

o

+

+

01

8.3 System Decks

For full documentation this appendix contains complete listings of the decks of all eight jobs making up the

experi-mental design system as run under the operating system IBM 360/65. These are as described in Chapter 5.

JOB 0.1: LSTPROG, JOB 0.2: GENPROG, JOB 1.1: DSSPROC JOB 1.2: DSAPROC, JOB 2.1: DSSPROG, JOB 2.2: DSAPROG, JOB 3.1: DSSIML, JOB 3.2: DSANAL.

Instead of particular problem statements and data, which are collected as examples in appendix 8.4, dummy statements have been inserted, the brackets indicating that statements may be, but, particularly in simpler problems, need not be inserted for the generation of proper PL/I programs (PROG) from the basic programs or procedures (PROC); _{see 6.1 for more} details.

s 0.1

/LSTPflC

JO' (

;LH,1F(r

I,lSLEVE:L1

1/IP

EXEC PUG

Dc

P1í)S:PPflCFDURE CPTJ(]NS(AIN)

DilL Apr 1TS ET

PiJFFE n SEQUFNT IAL PECOPO

rj

C.1D CHARACTEI (" )

PUT FILItSYSPRINT) PAGE LIST(1»JPUT');

PUT FILC(SYSPPTNI)SKjp(I);

Ü? ENDFI1EVVLIN) GC Tú S1CP:

¡TER:

GET

FILE(SYSIN)

FOITICARO) (A(P30H;

PUT FILE(SYSPRINT) SKIP(1) EDIT(CARD) (A(0));

WRITE FIL(DATASET) FROM(CARO);

GO YC hEP;

STOP: ENO ISTOS; 1*

I/SC

FX!C MODIFY

/IM.00

CC UNIT=2321,VI]LUME=SER=2321C7,DISPOLD //M.S'YSIN DO *

SCRATCI4 OSNAMF=USERF ILE .M6354.655.LO4D.L STPROG,VflL=2?l=22107 1*

I/AC

EXEC ALLCCATE

//A.USER DD DSMMEzUSERFh1E.M354.6535.LOAD.tSTPRCG,

//

OC8.MIT.STANOARO.1O*C.SPACE(1C24,(1O,l,I),,,ROUND)

//A.SYSIN

OD

I.

EXEC PLu //L.USER DO DSNAME=USERFIIE.M6354.6535.LCAO.ISTPPCG(IST),

II

D1SP=OLD

I.

JOB 0.2

//GENPROG JOB

/ICP

EXEC PL1C

//C.SYSIN

DC * GENPI1P:PROCEOU«E OPTIONS(PATN);

DECLARE (PLIPROC,PL1PROG,PLIDATA) BUFFERED SEQUENTIAL RECIPE) FILE, CRO CHARACTFR(BO);

ON ENOFILEISYSIM) GO TO STOP;

GET FILE(SYSIN) EDIT(CA*O) (AIRO));

IF suBsT(cARr,I,3)=' OS' THEN OC;

OPEN FILE(PLlPOC) O'TPUT;

GO TO PRCCIN;

[ND;rl SET

Gli

pp

¡

pi: CC.

C1L I F ILE( SYSI

LJIT(C4PU) IA(AO) )

;

IF SUBSTP(CARC,I,',)'PROB' THEN GO TO PROG;

pFrCIN:

WRITE FILE(PLIPRCC) FROM(CAPC);

GO Te PRCC;

C., OSE FILE(Pt.1PRCC) ;

(TB IN:

ST PRIC:

flN FNDFIL[-(PL 1'RCI.) (11 Tfl Dt,T!;

PFAD FILF(pt1PRrC) INTfl((A7C):

IF sUBSTE(rFr,l,l)='

'

TF-N O];

WRITr FILE(PlPRfl(;) FkflM(CAR[);

GD T RESTpCC;

END;

MF Pr,PPJJB:

GET FILE(SYSIN) EDIT(CAD) (A(RO));

IF SUBSTP(CAPC,1,4)'DATA' THEN GO Tfl PESIPPIC;

1F SIJBSTR(CAF.F,1,1)='

' THNDr;

WPITF FIIE(PIIPP!'G) FPUM(CiPO)

Gil TI) PERGPRCP;

FND;

GD TI PESTPPCC;

DA TA

GET FILF(SYSIN) FO1T(C4R)) (A(A0));

hRITF FI

(Pt1CATA)

Ci(CìPC);

GD To

DATi;

STOP:

FN!) GFNPL1P;

1*

I/SC

FXEC MODIFY

f/M.í)fl

DC _{UNIT=2321,VOLJMF=SFR=232107,DTSP=OLfl}

//M.SYSIN

D!)

SCRATCH CSNAMF=USFRF IL F _{.6535.LCAD.r,Er\PRCG ,VCL=2T321=232107}

/

I/AC

EFC M LCCA TF

//A.L'SFP Dr

_{DSNAE=tJSERFILE.4654.35.LO4D.GFJPRDG,}

Il

r)CB=MI T. ST ANI)APD. irr, SPACE= (1024, (lo, 1,1),, _{,ROUND )}

//A.SYSIN

01) * 1*

//LK

EXEC PLu

//L.JSEP

nO _{r)SNAiF=USEPF!LE.P6354.6535.LCAC.GENPRCC-(GEN),}

//

PISP=OLfl /,,

JIP 1.1

//DSSPROC

_{JOB (ME354,63c,1r,Oao,2co,SRI=1),*scHMJEcI4FI',dsçLFvF[=l}

//JDBLIP

DI)

_{DSNAME=USFRF!LE.6s.&'35.L0Afl.LSTPROGftsT),}

/1

DISP=CtJ)

I/SC

EXFC MODIFY

//M.))))

OF _{UN!T2321,VGLUMF=SER2321C7,rJsp=flLr}

/IM.SYSIN OD

SCRATCH CSNAMF(PSFRFILF_{.M354.653S.DATA.DSSPR0C,VCL?321=232107,}

_*

PURGE

1*

I/AC

FXFC _PGM=IFEBRI',

//US

or. _{OSt'AME=USFRF!LF.M6354.653S.C4TA.OSSPRflC,}

_*

/1

_{1)!5P=(NFW,CATIG),VflL=RFF=PFNTCFLt, *}

/1

_{flCP=(PFCF4=F3,LRFCL=cC,cLKSI7E16nC), *}

//

_{SPACF=(1oOO,(1O,2),,,pnurr),LFFL=FxpCr=r,CeCc}

1*

I/St

FXEC PDM=LST //SYSPPINT í SYSCLT=A //L)ATASET OD

DSNAMF=ucEFJLF.63.ock5.DATA.cSçpprc,cTçp=nLC

//SYSIN

FC

OSSI 'L: F}.kCCEfltAF CPI IONS (frt TN)