Methodik der rechnergestützten Simulation — Fachgespräche vom 10.–11. Mai 1973

Complete English translation of the original German-language document (425 pages).

Methodology of Computer-Aided Simulation

Workshop Proceedings, 10–11 May 1973

Organized by the Institute of Data Processing in Technology, Gesellschaft fur Kernforschung, Karlsruhe, and the Institute of Computer Science, University of Stuttgart

KFK 1845

Kernforschungszentrum Karlsruhe — KFK 1845

Institute of Data Processing in Technology Gesellschaft fur Kernforschung Karlsruhe

Institute of Computer Science University of Stuttgart

Methodology of Computer-Aided Simulation Workshop Proceedings, 10–11 May 1973, Karlsruhe

Organizing Committee: O. Drobnik, E. Holler, F. Schumacher (Karlsruhe) H. Beilner, P. Christ, H. Ress, H. Rzehak, G. Stubel (Stuttgart)

Gesellschaft fur Kernforschung m.b.H., Karlsruhe

[page 2: figure only]

Summary: Methodology of Computer-Aided Simulation

On 10–11 May 1973 a workshop on the methodology of computer-aided simulation was held at the Karlsruhe Nuclear Research Center. The event was organized by the Institute of Data Processing in Technology of the Gesellschaft fur Kernforschung, Karlsruhe, and the Institute of Computer Science of the University of Stuttgart. The purpose of the workshop was an intensive exchange of ideas among specialists in the field of simulation on fundamental problems that arise in the planning and implementation of simulation projects. The report presented here comprises the papers delivered during the workshop, together with supplementary information providing an overview of the composition of the group of participants and the fields of activity of the presenters.

Abstract: Computer Simulation Methodology

A Workshop on “Computer Simulation Methodology” organized by the Institute of Data Processing in Technology of the Karlsruhe Nuclear Research Center and the Computer Science Department of the University of Stuttgart was held from May 10–11, 1973 at Karlsruhe. The workshop’s aim was to provide for an intensive exchange of thoughts among simulation specialists on fundamental problems in computer simulation design and experiments. This report includes all papers presented at the workshop and gives a survey on the referees and their fields of activity.

[page 4: figure only]

Preface

Computer-aided simulation as a tool for solving complex problems that are barely tractable by analytical means is finding ever wider application across the most diverse fields of knowledge and areas of practice. Individual users have, for the most part independently of one another, developed various simulation methods tailored, understandably, to their own specific problems. The growing importance of simulation as a problem-solving method appears to justify treating it as an independent field of research. Only in this way is it possible to investigate its universally valid foundations in a systematic and coordinated manner on a broad basis. This process can be set in motion only through dedicated simulation conferences — as has already been the practice in the United States for many years, among other places.

Contacts between the Institute of Computer Science at the University of Stuttgart and the Institute of Data Processing in Technology of the Gesellschaft fur Kernforschung Karlsruhe, which arose on the basis of shared interest in problems of computer-aided simulation, led to the idea of organizing a relevant working conference to analyze the state of the art in the German-speaking world.

The organizing committee was agreed from the outset to reserve the conference for discussion among specialists. A participant group as heterogeneous as possible was to integrate the most diverse areas of interest and fields of application, which naturally made it more difficult to formulate overarching perspectives on the subject areas to be addressed at the conference.

The organizers decided to emphasize the methodology of computer-aided simulation as the guiding theme of the conference, and to open the following thematic complexes for discussion:

Possibilities and limits of simulation
- Definition of concepts and delimitation from other methods
- Types of model formation
- Fields of application (performance enhancement, new planning, …)
Design and implementation of simulation models
- Simulation objectives (formulation of the question complex to be answered)
- System analysis
- Model synthesis (structuring, depth of modeling, …)
- Implementation aids (languages, program systems, …)
- Ease of use and user-friendliness
Validation and model deployment
- Verification, calibration, validation
- Experimental design, results analysis, optimization

Within the framework of these themes, each participant was expected to contribute to the discussions in one of the following two forms:

a) Presentations of approximately 20–30 minutes in duration, with the aim of:

Presenting new developments and trends in the field of simulation methodology
Reporting on aspects of applying known simulation methods in concrete projects, as well as on the motives for choosing particular methods and experiences in their application.

b) Discussion contributions of approximately 10 minutes in duration on problems currently arising in simulation projects that are in the planning or development phase.

In order to make the character of a specialized technical discussion clear from the outset, it seemed to the organizers particularly important that the contributions should present the methodological approach in greater detail than the significance of the problem solution for the respective specialist field. The fact that some contributions did not entirely meet this requirement may be explained by the short notice on which the conference was convened.

The general nature of the thematic scope, and the admission of reports on completed as well as on still-ongoing or merely planned projects, was intended to publicize current activities alongside the established body of knowledge. In particular, the presentations were intended to show the effects of applying simulation in different fields, so as to enable the recognition of problems as specifically simulation problems. In order to promote the always-necessary discussion, emphasis was placed on keeping the group of participants small, even though this diminished the claim to representativeness. In this connection, attention is drawn to the results of the participant survey on the simulation workshop, appended to this proceedings volume, which attempts to show — in addition to a detailed breakdown of conference participants by affiliation with industry, university, etc. — their respective experience with simulation.

The conduct of the conference substantially validated the deliberations of the organizing committee. It became apparent, however, that active participation by 40 participants in one of the two forms of contribution chosen by the organizers allowed too little scope for discussion of the problems raised within the space of two days. Nevertheless, an intensive exchange of ideas could be stimulated, which will have a particularly positive effect on future communication among the workshop participants.

The organizing committee thanks the Gesellschaft fur Kernforschung and the University of Stuttgart for their organizational support in the preparation and conduct of the conference, and in the publication of these proceedings.

Organizing Committee:

Karlsruhe: O. Drobnik, E. Holler, F. Schumacher

Stuttgart: H. Beilner, P. Christ, H. Ress, H. Rzehak, G. Stubel

Title	Author	Page
Use and Design of Systems for the Real-Time Simulation of Time-Continuous Systems	H. Rzehak	1
Fundamental Design of a Hybrid Simulation	R. Vogel	16
Logical and Functional Simulation of a Complex Hardware Controller for Data Pre-processing	H. Weisschuh	25
Dynamic Simulation as a Decision Aid in Educational Planning	H. Bossel	33
Possibilities of Combinatorial Analysis of Simulation Models	G. Petrich	65
A Program System for the Simulation of Road Traffic Systems	H. Ress	73
Influence of Model Structure on Solution Effort in Dynamic Electrical Networks	W. Jentsch	78
Tasks and Technical Solutions of Computer-Aided Simulation at VW	D. Boge, H.G. Siepmann	94
Simulation Problems in the Areas of Mechanical Engineering and Reactor Technology	E.G. Schlechtendahl	99
Uniform Programming of a Hybrid System at the Problem-Oriented Level for the Simulation of Real-Time Problems	V. Hecht	109
SCALE — A Digital Implementation Aid for Analog and Hybrid Simulations	D. Heppner	121
The MUNICH Simulation Programming System	M. Feilmeier	145
CSMP-I: An Interactive Simulation Program System for the Simulation of Time-Continuous Systems	H.J. Burkhardt, Giessler, Mathe	147
Proposals for the Extension of DYNAMO	O. Kolbe	155
Heuristic Procedures in the Simulation of Management Planning Models	G. Stubel et al.	162
Computer-Aided Simulation for the Development of Manufacturing System Structures	A. Reinhardt	173
The Simulation Project: Ore Handling and Mill Feed Preparation, Schweigern	W. Kleemann	187
The Applicability of Diffusion Models for Environmental Protection, Using the City of New York as a Concrete Example	Ch.A. Raehmel	193
Test and Measurement Equipment for a Simulation System for Investigating the Dynamic Behavior of Operating System Software	J. Nehmer	208
Model Formation in the Context of Simulation of Subscriber Systems	R. Isernhagen	220
User-Friendliness in Simulation Technology	K. Lagemann	228
Simulation in Communication Traffic Theory: Problem Formulations and Programming Languages	G. Kampe, P. Kuhn, M. Langenbach-Belz	240
Simulation of Message Sources in Block-Oriented Simulation Models	H.J. Burkhardt, E. Hinsch	264
Simulation of Core Memory Allocation in an Electronic Data Processing System	W. Kistler	284
Simulation of Computer Networks with Clocked Information Transfer	U. Herzog, G. Kampe, M. Langenbach-Belz	293
Simulation of a Computer Network System: System Analysis and Model Synthesis	O. Drobnik	304
Simulation of a Computer Network System: Experimental Design and Validation	F. Schumacher	319
On the Validation of Discrete Simulation Models	H. Beilner	332
Sample Size in Monte Carlo Simulation	M. Helm	344
On an Adaptive Model for Attitude Simulation of a Satellite	R. Kammüller	352
Simulation of Controller-Human Behavior in Human-Vehicle Systems	W. Berheide, G. Johannsen	367
Determination of the Statistical Error in the Simulation Model of a Subscriber Computing System	G.U. Weigand	375
Investigation of the Address Translation Mechanism of the TR440 by Means of Simulation	E.F. Pantele	402
Results of the Participant Survey on the Simulation Workshop	—	410

Use and Design of Systems for the Real-Time Simulation of Time-Continuous Systems

Dr. H. Rzehak

1. Introductory Remarks on Model Formation and Depth of Modeling

The most common task in the simulation of time-continuous systems — referred to hereafter simply as dynamic systems — is the reproduction of technical systems. The relationships of the real system are then given by physical laws. The study of a real system always requires certain idealizations — whether in order to perform a quantitative analysis using known methods, or in order to limit the effort involved. These idealizations are justified by physical considerations, i.e., one determines by means of a qualitative analysis whether they have a significant influence on the desired statements about the real system. A model of the real system is obtained, which is then studied as a representative substitute for the real system. The desired depth of modeling results from the idealizations applied to the real system. In the course of an investigation one will generally progress from a low to an ever-increasing depth of modeling, i.e., from a strongly idealized system to increasingly realistic systems.

First, the dynamic system is decomposed into subsystems. At a low depth of modeling, this decomposition will be given by the construction of the system from individual assemblies. This already incorporates, however, the idealization that the system can be described by lumped parameters. An electrical network, for example, can only be described by the action of discrete components as long as the spatial dimensions of the real components are small enough that their effect can be thought of as concentrated at a point. The mutual interaction of the subsystems — characterized by the interconnection of the subsystems — will in the model likewise contain only the primary effects. The mutual influence of drive units through the common power supply, for example, will remain unconsidered.

The subsystems have one or more inputs and, as a rule, one output. They are fully characterized by the relationship between the output quantity and the input quantities. This relationship is frequently describable by differential equations. In many cases these can be determined by physical reasoning. In the case of experimental determination it must be noted that the relationship cannot be described by value tables, since the differential or integral operator effects a mapping in function spaces. By means of parameter estimation methods, experimental statements for the description of a subsystem can indeed be obtained, but these methods presuppose assumptions about the structure of the equations used for the description. If these assumptions are not valid, no correct description is obtained either. The model so obtained can now be studied in two principally different ways. One can set up the differential equations of the overall system and solve them. Even the formulation of the equations of the overall system sometimes presents considerable difficulties — for example, analytical representations of empirical functions are required — but in any case it means additional work. The other method is to simulate the overall system. In this approach the subsystems are represented by dynamic processes (the simulation model), which realize the model used for description with certain idealizations. This can be a numerical process or an analog model. The formulation of the equations for the overall system is avoided. There is a direct relationship between the quantities of the real system and the quantities of the simulation model.

Modifying the model for individual subsystems is possible without altering the rest of the model. The relationship between these model concepts is shown in Figure 1.1.

Figure 1.1 — Relationship between real system and simulation model

Real System --------> Simulation Model
     |                      |
Idealizations          Idealizations
     |                      |
     +----> Model for ----->+
            Description
            of the System
                 |
           Mathematical
           Description

2. Representation of the Subsystems

Computer-aided simulation can develop its full flexibility only when the simulation model can be readily adapted to changed problem formulations. It is expedient to use a simulation system that provides aids for the convenient representation of the subsystems and their interconnection. For high comfort requirements, this will amount to a complete program system.

There are various possibilities for the representation of the subsystems. A numerical process will be set up that approximates the model description. If the subsystems are described by differential equations, the numerical process consists of the step-by-step solution of the differential equations. It is well known that these are only approximation methods. For the execution of the simulation these can be programmed directly. Greater convenience is achieved by using block-oriented programming of the kind provided for by the CSSL recommendations, e.g., through the use of CSMP. The particular advantage is that the construction of the simulation model from subsystems (blocks) is taken over directly into the programming. Since the blocks in the digital computer can only be processed sequentially for each solution step, the computational effort is considerable. It could be reduced if several blocks (subsystems) were combined and the numerical solution of the resulting combined block were programmed directly. This does, however, increase the number of blocks required in the simulation system.

Instead of having a subsystem (block) represented by a numerical process, an analog model can also be used by appropriately programming an analog computer. At the problem-oriented level, programming can likewise be carried out in a language following the CSSL recommendations. Such languages (e.g., CSMP) are in principle machine-translatable into a computing circuit for analog computers. Since the use of an analog model does not involve a numerical process, the deviations of the simulation model from the idealized description are of a fundamentally different kind. They result from the fact that the computing elements deviate from their ideal behavior. Further essential differences are the temporally correct parallel simulation of the subsystems, and the fact that the analog computer is a fixed-point machine, i.e., the quantities must be transformed into the desired range, usually the interval (−1, 1).

These representations of the subsystems presuppose that a valid description of the subsystems for the desired depth of modeling is known. If this is not the case, and if the corresponding investigation is also to be forgone on account of high costs, then the corresponding real hardware component can be used in the simulation model. This makes appropriate provisions necessary in the conception of a simulation system — provisions that are essentially also required when numerical processes and analog models are used in combination (hybrid computer systems). It is intuitively clear that an analog model can be replaced comparatively easily by a real hardware component. The essential points in this regard are:

The input functions for analog sub-models and real hardware components must be passed over in a timely manner. In this process, not only the values at discrete time points influence the result; rather, the entire course of the function has an influence.
The serial execution sequence in the digital computer must be synchronized with the model time of the simulation run.
Appropriate hardware is needed for data conversion, and this should be supported by the programming system.

An important special case of the use of real hardware components is the human being in the simulation run. Here it applies that too few, or too incomplete, descriptive models for human behavior in dealing with technical systems exist. Furthermore, it should be the goal of progressive technology that technical systems be adapted to human beings, and not — as was frequently the practice in the past — that humans must adapt themselves to systems developed without taking human behavior into account. This requires a faithful reproduction of all the communication media through which the exchange of information between a human being and a technical system takes place.

3. Special Problems of the Mixed Use of Digital and Analog Models and Real Hardware Components

The subsystems of a dynamic system effect a mapping of the input functions into the output function in the space of real, continuous (in special cases piecewise-continuous), bounded functions. Since numerical processes mean operations on values of variables, the independent problem variable (the time axis) must be discretized. The continuous functions must be replaced by discrete functions. For a finite time interval these can be represented by a finite number of variables. In contrast, both in real hardware components and in analog models, the elements of the space of real, continuous, bounded functions are represented directly; the mappings effected by the subsystems are thus represented in the original space. For the cooperation of these different representations of the subsystems, not only is the conversion of individual values from digital representation to analog and vice versa required, but rather the mapping of discrete functions into continuous ones and vice versa. Digital simulation models on the one hand, and analog models or real hardware components on the other, therefore represent operators in different spaces. For their cooperation, operators are needed that map these spaces into each other. In this way, subsystems appear in the simulation model of the overall system (namely the function transformations) to which no subsystems in the real system correspond. The question of how far deviations from the behavior of the real system result therefrom must be seen in connection with the choice of digital models, as will be explained in the following.

The mapping of time-continuous functions into discrete functions will naturally be carried out by taking over the function value at the discretization point. Since the simulation runs in real time — the elapsed machine time represents the independent problem variable — the analog functions to be converted are sampled at equidistant…

[page 18 ends here — text continues on subsequent pages]

[Pages 19–36: Chapter continuation — Hybrid Simulation, Practical Setup (Dornier)]

[Page 19 — continued from prior section]

For the above reasons one arrives almost inevitably at the hybrid computer, in whose digital section the mathematical model is executed and in whose analog section the controller (with servo motors) is simulated.

4. Computer Configuration

Dornier has a complete hybrid computing system available, consisting of:

Digital computer SDS 9300 with appropriate peripherals
Analog computer BECKMANN EASE 2133
Interface BECKMANN with A/D–D/A converters, interrupt lines, etc.
Flight control station DORNIER
Symbol generator with display DORNIER
Furthermore: three-axis table, various plotters, etc.

5. Programming Language

For the above computer configuration there exists a main program “HYBRIDMASTER”, which handles all necessary control functions of the hybrid computer (e.g., clock control, mode control of the analog computer, etc.) and allows the actual problem (mathematical model) to be written in the form of FORTRAN subroutines. The well-known advantages of FORTRAN programming naturally apply (fast programmability, easy readability, easy testing, etc.).

6. Mode Control by HYBRIDMASTER

The following states of the hybrid computer can be called up by pressing a key:

PARASET : Analog computer in mode “Pot set”; setting of potentiometers by the digital computer or by hand; reading in of parameters.

[Page 20]

IC (INITIAL CONDITION) : Analog computer in mode “Set initial conditions”; execution of a program segment through which all initial conditions of the mathematical model and of the analog computer are established.

COMPUTE : Execution of the mathematical model (actual simulation) and A/D–D/A conversion at a prescribed clock interval (analog computer in mode “Continuous computation”).

HOLD : “Freezing” of the current simulation state (analog computer in mode “Hold”).

DIAGN : Output of a diagnostic of the “frozen” simulation state (compute diagnostic) or of the IC state (IC diagnostic).

7. Temporal Sequence Within a Clock Step, Real Time — Achievable Clock Intervals

Hybrid simulations are meaningfully applied only when the problem (simulation of an aircraft) is to run in real time.

Because the mathematical model, written in FORTRAN, does not exhibit a constant execution time (variable execution time for DO-loops, interpolations, etc.), an external clock generator must ensure that the time required for a single pass through the mathematical model always remains constant (see diagram “Timing sequence within a clock interval”).

The most important hybrid simulations carried out at Dornier have program lengths between 8 and 20 kWords of core memory requirement.

[Page 21]

These are the simulations: DO 31, KIEBITZ, AERODYNE, ALTITUDE RESEARCH ROCKET, etc.

The clock intervals of the above simulations lie between 10 and 40 ms (100–25 Hz), with 40 ms being achieved in most cases (10 ms only in special cases). These clock intervals are small enough to obtain reasonable integrations of the accelerations and to drive a display at a reasonable frame rate.

8. Integration of Real Hardware into the Simulation Process

When the simulation model has been refined to such an extent through wind-tunnel measurements, etc., that one can speak of a final phase of simulation, steps are taken to incorporate real hardware into the simulation process:

a. Integration of the actual flight controller (the analog section of the hybrid computer then only handles the adaptation). In this way any errors in the actual controller can be eliminated (elimination of the simulation of the controller).

b. Integration of control surface actuators, control linkages (backlash in the linkage!) and control surfaces, with the surface deflection angle picked off directly at the surface by means of a potentiometer. (Elimination of the simulation of the actuators, time constant!)

c. Integration of the sensor packages — vertical gyro and rate gyro: For this, the attitude angles of the aircraft as delivered by the mathematical model must be fed to a three-axis table on which the vertical gyro and rate gyro are mounted. The vertical gyro and rate gyro then supply the actual attitude angles and angular rates that are required by the flight controller. (Elimination of the simulation of the hysteresis of the vertical gyro

[Page 22]

and of the measurement inaccuracies of the rate gyros.)

At this stage of the simulation nothing of the hybrid computer remains in use. Only flight mechanics and aerodynamics are still simulated by means of the mathematical model in the digital computer. The hybrid computer has transitioned into a process computer with corresponding peripherals.

9. Limits of Hybrid Simulation — Outlook

The most significant limit of hybrid simulation lies in the fact that, because of minimum requirements on the mathematical model, a certain program length and with it a minimum clock interval cannot be underrun.

Shannon’s sampling theorem states that the clock frequency must be at least a factor of 2 higher than the highest natural frequency of the mathematical model.

In practice it has been shown that this factor is not 2 but lies between 6 and 7. For clock frequencies on the order of 25 Hz, the maximum natural frequency of the aircraft thus works out to 3–5 Hz. Aircraft with higher natural frequencies (e.g., rockets) can therefore be hybrid-simulated only in special cases.

The second limit of hybrid simulation lies in the inadequate measurability of many influencing variables on the mathematical model (e.g., inaccurate wind-tunnel measurements).

These few examples are intended to show that hybrid simulation is, after all, only a tool in the

[Page 23]

development and design of new aircraft. In conclusion it should be noted that even the best hybrid simulation cannot replace actual flight tests.

[Page 24 — figure only]

[page 24: figure only]

Diagram: “Timing sequence within a clock interval”

The diagram shows the sequence of operations within one clock cycle (clock interval), from top to bottom:

INPUT n — Analog-to-digital conversion (e.g., conversion of the throttle lever position of the engine, conversion of control stick signals, conversion of control surface deflection angles, etc.)
Engine model
Flight mechanics and aerodynamics
- (Integration of accelerations and angular accelerations; transformation into the earth-fixed frame; computation of display quantities)
Digital-to-analog conversion (e.g., conversion of attitude angles, angular rates, display quantities, etc.); time shift (T(n) > T(n−1))
Output n
Wait loop
A/D conversion
← Clock

The diagram illustrates how within each clock tick the digital computer performs the full model computation and data conversion cycle, with a wait loop padding the remainder of the clock interval until the next tick triggers a fresh A/D conversion.

[End of translated range, pages 19–36. Pages 25–36 were not present in the extracted text layer of this document; the extracted content ends at page 24 of this document’s internal numbering (corresponding to document page 36 in the 1-based page count of the PDF file). The final page contains only the timing diagram described above.]

Logical and Functional Simulation of a Complex Hardware Control System for Data Preprocessing

by H. Weisschuh, Institut für Nachrichtenvermittlung und Datenverarbeitung, Universität Stuttgart

1. Introduction

Digital hardware control systems are widely used today for controlling technical processes. These systems are in some cases very complex in their structure, and a considerable investment in hardware is required for their implementation. The development and construction of such control systems gives rise to the following problems:

Verification of the logical function for fundamental errors is only possible after a control system has been built
The effects of a faulty environment are difficult to check
Fault-finding is hampered by inadequate operator convenience
Comparison of several design variants is only possible with difficulty
Modifications or extensions are often feasible only at great expenditure of time and money
Investigation of the interaction of multiple control systems is not possible

One aid for solving these problems is the simulation of the control system with the help of a digital computer. Errors in the logical function are detected immediately. Investigation of the effects of a faulty environment is possible by entering incorrect input data. Fault-finding is facilitated because information about internal states of the control system can be printed out. Comparison of several design variants can be carried out with different program variants, and changes to the system can be implemented by means of simple modifications to the simulation program. The logs produced during simulation are particularly well suited to change monitoring and documentation. The interaction of several control units can be investigated through the cooperation of several simulation programs, each of which models one control system. The following discussion uses the example of a data preprocessing unit from a projected telephone switching system to demonstrate the possibilities offered by simulation.

2. Structure and Simulation of the Control System

2.1 Structure and Mode of Operation

The basic structure of the control system of the telephone switching system considered here [1] is shown in Figure 1. The assemblies for speech transmission have been omitted for clarity, since they are not required for understanding the simulation.

[Figure 1: Structure of the control system of the telephone switching center under consideration.]

The telephone subscribers are connected to the switching system via remotely controlled peripheral units — so-called concentrators. From the perspective of the control system, these remotely controlled peripheral units have the task of transmitting, on one hand, information about the status of the subscriber terminals (telephone sets) and, on the other hand, control information entered by the subscriber (e.g., dialed digits) to the switching center in multiplex operation. In addition, they must execute certain functions in response to messages from the switching center.

Each peripheral unit is remotely controlled by a data preprocessing unit in the switching center. This data preprocessing unit has the task of processing the information coming from the periphery, executing certain routine tasks, and forwarding the resulting outcomes in the form of messages to the central control computer. Furthermore, it must cause the peripheral units to perform certain functions in response to messages from the central computer. For control purposes, the data preprocessing unit has a hard-wired microprogrammed controller and various data memories for storing information pertaining to the peripheral unit.

The central control computer controls and monitors the entire switching system. The data preprocessing unit reduces the data flow to the central computer and relieves the central computer of routine tasks, thereby reducing its load.

The data preprocessing unit is connected in each case to the central control computer via one data channel and to a peripheral unit via another. Data exchange takes place via transmit registers (SR) and receive registers (ER), each of which can hold one message. These registers constitute the external interface. When a message arrives in one of the receive registers (ER2 or ER3), a microprogram specific to that message is started. During its execution, changes are made to the data memories of the control system. The result of the microprogram execution is instructions in the form of messages that are transmitted either to the peripheral unit or to the computer via the transmit registers (SR2 or SR3). Corresponding to the various incoming messages, different microprograms are present in the control system.

2.2 Logical Simulation of the Data Preprocessing Unit

In order to test the logical sequence of the various microprograms and their mutual influence through the use of information from the same data memories, a simulation program was developed [2]. The flow diagram is shown in Figure 2 (see page 5).

The program is divided into a part for interface supply and a part that constitutes the actual simulator. The interface supply section serves to enter messages — which in the real system come from the peripheral unit or from the central control computer — into the receive registers ER2 or ER3, and conversely to output the messages generated as a reaction to the input in the transmit registers SR2 or SR3. The messages in the registers represent bit patterns and generally contain an identifier and various parameters.

To facilitate use of the program, the messages can be entered and output using mnemonic abbreviations, and the various parameters contained in the message alongside the identifier can be expressed as numbers. This yields easily comprehensible documentation. Furthermore, the interface supply section enables — on request — output of the contents of the data memories of the simulated data preprocessing unit.

After the entered message has been written into the corresponding receive register, the actual simulator is activated. This is implemented as a macro-program simulator [3]. The decoding section retrieves the message standing in one of the receive registers and activates a subroutine specific to that message. This subroutine performs the same tasks as the microprogram to be simulated. The result of the subroutine execution then yields a message that is written into the corresponding transmit register. The task of the simulator is thereby complete, and the interface supply section outputs the message standing in the simulated transmit register.

For investigation of faults, incorrect messages — such as might arise from transmission disturbances between the transmit and receive registers — can be entered. Furthermore, the sequence of messages coming from the peripheral unit, which in the real system have a specific order, can be altered, or messages can even be suppressed entirely.

[Figure 2: Flow diagram for the logical simulation.]

2.3 Functional Simulation of the Data Preprocessing Unit

The control system of the computer-controlled telephone switching system shown in Figure 1 contains several data preprocessing units. To test the functional interaction of these various units with the computer, it is not necessary to implement all of these units in hardware and connect them to the central control computer. It is possible to replace the data preprocessing unit with a simulator in accordance with Section 2.2 within the central control computer and to connect the peripheral unit directly to the central control computer. The resulting structure of the overall system is shown in Figure 3.

[Figure 3: Structure of the control system of the telephone switching center under consideration, with simulated data preprocessing units.]

The input-output interface of the computer now presents to the peripheral control unit the interface of the data preprocessing unit. (If the interface between the peripheral unit and data preprocessing unit and the interface between the data preprocessing unit and the central control computer should differ, an interface conversion within the central control computer is required, the implementation of which is, however, often feasible by program.)

The individual simulators are controlled by a superordinate control program. This superordinate control program transfers control to the individual simulators when a message is present in the real receive register of the control computer (message from the peripheral unit to the data preprocessing unit) or in the simulated receive register of the simulator.

According to Figure 3, all data preprocessing units are replaced by simulators in the central control computer. Mixed operation is of course also possible — that is, one data preprocessing unit is implemented in hardware while the others are replaced by simulators. This makes it possible to test the data preprocessing unit under real operating conditions while at the same time testing the interaction of several such control units without excessive effort.

3. Concluding Remarks

The logical simulation described in Section 2.2 permits verification of the logical sequences of a control unit. Investigation at the circuit level (construction using various digital components and their interconnection) is not yet possible in this way. Such an investigation could, however, also be carried out by means of simulation. Several program systems for this purpose are known in the literature [4, 5].

The functional simulation described in Section 2.3 permits verification of the interaction of several control units. It must be noted, however, that the real-time behavior of the control system cannot be verified, because on one hand the program execution times of the simulators delay the central computer for its own control programs, and on the other hand the simulators operate sequentially and not in parallel.

The simulation program was written in the assembly language of the central control computer in order, on one hand, to use as little memory space as possible, and on the other hand to keep the execution times of the simulator small.

4. References

[1] Katzschner, L., Lörcher, W., Weisschuh, H.: “On an Experimental Local PCM Switching Network.” Congressbook of the International Zürich Seminar on Integrated Systems for Speech, Video and Data Communications. Zürich, 15–17 March 1972; B6.

[2] Gärtner, E.: “Programm zur Simulation der Konzentratoranschlußschaltung einer PCM-Vermittlungsstelle” [Program for simulation of the concentrator connection circuit of a PCM switching center]. Studienarbeit Nr. 393 am Institut für Nachrichtenvermittlung und Datenverarbeitung, Universität Stuttgart.

[3] Risak, V.: “Simulation von Digitalrechnern” [Simulation of Digital Computers]. Computer Monographien Bd. 6, Carl Hanser Verlag München 1971.

[4] Pfeuffer, K.: “Die Grundlagen des Programms ATEDIS” [The Foundations of the ATEDIS Program]. Lecture Notes in Economics and Mathematical Systems Bd. 78, zur 2. Jahrestagung der Gesellschaft für Informatik, 2–4 October 1972.

[5] Clausert, H., Kahlert, I.: “Untersuchung digitaler Schaltungen mit dem Programmsystem DICAP, 1. Teil: Simulation” [Investigation of Digital Circuits with the DICAP Program System, Part 1: Simulation]. Elektronische Datenverarbeitung 11 (1969), pp. 443–451.

Dynamic Simulation as a Decision-Making Aid in Educational Planning

Hartmut Bossel, Institut für Systemtechnik und Innovationsforschung, 75 Karlsruhe-Waldstadt, Breslauerstr. 48

Abstract

In contrast to purely technological and economic processes, the consequences of socio-political decisions have hitherto been difficult to predict with any great degree of reliability. This is due in part to the dominant role of human behavior in such systems, and in part to the high degree of complexity of their structure with a large number of parameters and variables that are for the most part not precisely measurable. Consequently, the dynamics of the system remain unknown and are estimated only intuitively by the decision-maker. Occasional wrong decisions are unavoidable.

In the present work, the suitability of system-dynamic methods as a decision-making aid in educational planning in the higher-education sector was investigated. Specifically, the influences of tuition fee policy, scholarship policy, and curriculum policy on dropout rates and performance of university students of differing abilities and financial need were to be studied. In addition to financial quantities (study costs, living costs, income of various kinds), the simulation works with a larger number of quantities that are not measurable or only poorly measurable (motivation, frustration, performance pressure, education, educational discrepancy, etc.). The results show that careful and thorough dynamic simulation of “soft” socio-political systems can deliver “reasonable” results and can serve as a decision-making aid.

Introduction

American colleges and universities face the problem of a very high dropout rate. The national average shows that 53.3% of entering freshmen leave higher education during the course of the four-year study period [1]; only half of those who leave apply to other institutions at all. These dropouts are associated with personal hardships, social costs, and financial losses for the student, the student’s parents, the institution, and the state.

Attempts have been made to construct a profile of the typical dropout student through factor analysis [1]. From these studies it is known that the chances of persisting are greater the higher the student’s high-school grades were and the better the student performed on aptitude tests. Further significantly positive factors are largely secured financial support from parents, scholarships or savings, and the fact that the student is male and also a non-smoker who aspires to a higher academic degree (Master’s or Doctorate, not merely a Bachelor’s).

These results are of little practical use to the college administrator and the relevant committees, unless they were to admit only talented, male, non-smoking children of wealthy parents in order to keep the dropout rate low. (This practice is centuries old at private Ivy League colleges.) For the typical higher-education administration, which cannot select its student composition, the problem lies at a different level: it is necessary to investigate which educational-policy decisions can reduce the dropout rate as much as possible. At this point, however, one immediately faces a double dilemma that makes intelligent decision-making extraordinarily difficult: neither can appropriate experiments be conducted for reasons of time, cost, and ethics, nor can simple cause-and-effect relationships be identified that determine the decision to drop out. A simple analysis quickly reveals that a dropout decision can be made by an individual for a whole series of reasons, which can occur individually or in combination: financial circumstances, poor academic performance, insufficient motivation, frustration — to name only the most important. These quantities must be incorporated into the decision-making process of the educational planner before any relevant statements can be expected. However, intuitively estimating the influences of these (and other) factors on the dropout decision of the student, or of a population of students — as has been the practice until now — exceeds the capabilities of the human brain. (There are nonetheless reportedly people who trust themselves to do this.) If, however, an explicit theory existed (i.e., a conceptual model), the consequences of decisions could be worked through on computing systems relatively painlessly. These considerations led the University of California (Santa Barbara campus) in spring 1972 to commission a study in which the behavior and decision-making process of the individual student was to be modeled with the help of dynamic simulation. The study was carried out with an expenditure of one man-month and a total computation time (IBM 360/75) of one hour (including debugging and sensitivity analysis). The study is divided into two sections, which are briefly described here. First, a model of the behavior of the university student had to be developed. Using this model, a large number of simulations were then carried out in order to determine the influences of various factors on the behavior of the simulated student. The model was then used to make proposals for improvements to the course timetable and the tuition fee structure.

There are as yet relatively few attempts to simulate human behavior dynamically on computers (for others, see [2]–[9]). The method and the results should therefore be examined very critically before they find wide application. With all due caution, the view taken here is that the simulation of human behavior opens up a fruitful new research area that will particularly extend the toolkit of the decision-maker and lead to better and more humane decisions.

Why computer-supported simulation of human micro-behavior in a given situation? There are several good reasons. All of them seem to justify efforts in the field of simulation to investigate its reliability and utility as a tool for behavioral research and as a decision-making aid:

Behavioral experiments running over years are normally neither feasible nor ethically permissible.
External conditions and the subjects themselves change over time to an extent that makes repetition of the experiment with an altered parameter — but otherwise under identical conditions — impermissible.
Decision-makers rarely have time to wait for the outcome of real-time experiments in behavioral research.
In simulations, different courses of action can be studied, even if they must be considered unusual or extreme.
Computer-supported simulation requires a precisely formulated quantitative model — that is, the formulation of a very explicit theory. In contrast to a verbal or intuitive model, the computer model is unambiguous and open to discussion and improvement.
The development of a simulation model promotes clear thinking about the subject of investigation. In the course of the development process, gaps in knowledge emerge that can often be filled by simple real-world experiments.
The human brain can recognize and describe even complex system structures from a detailed perspective admirably well. It can establish parameters and variables and the dependencies between variables. These tasks cannot yet be taken over by computers. Human capabilities are, however, extremely limited and unreliable as soon as it comes to the accurate prediction of the dynamic behavior of complex systems — that is, fundamentally, to the solution of simultaneous nonlinear differential equations. Here the computer must step in. It is to be expected that human power of recognition, extended by the infallible computational capacity of the computer, must lead to better results.

General Approach

When the problem of premature dropout is considered, it is embedded in a large population of individuals of differing abilities, interests, motivations, and financial situations, interacting with a university that is characterized by certain administrative features, course timetables, teaching staff and faculties, overheads, and academic climate. This interaction appears as a dynamic process that extends (for the American universities considered here) over four years and ends — perhaps — with the award of the Bachelor’s degree. This complex dynamic process encompasses not only quantifiable variables (financial variables) but also others that are difficult to quantify (grade pressure, frustration, etc.). The process also depends entirely on individual decisions and factors. It is obvious that simulation of individual behavior is necessary in order to achieve even a degree of relation to reality. The aggregate behavior of a student population could then be studied through statistical investigation of a large number of probabilistically simulated students. For reasons of economy, however, this path was not taken here.

This sets the task of time-dependent (dynamic) simulation of a complex deterministic system of mostly continuous variables, where only a portion of the variables and parameters can be readily and unambiguously quantified. Furthermore, the structure of the system is highly fuzzy. Even if a system structure could be distilled out, uniqueness would not thereby be proven.

This raises the question of whether simulation can yield meaningful results in such a case at all. It appears that this question can be answered affirmatively for two reasons. First, when capturing fuzzy system structures, it is repeatedly found that even system structures developed independently of each other (for the same purpose) generally do not differ from one another in essential details. Differences can usually be resolved through discussion and further investigation. In other words, even from fuzzy systems, it is generally possible to extract iteratively a system structure that reflects the essential characteristics of the system. Second, the non-measurable or poorly measurable quantities (motivation, frustration, etc.) do not satisfy conservation laws in a behavioral simulation as physical quantities do. They can therefore be specified and used on relative scales, with certain points (minima, maxima, zero crossings, etc.) often being relatively easy to determine. From these two points an important further conclusion follows: the dynamic behavior of the system is described qualitatively correctly, provided that the functional dependencies of the process are continuous, provided these dependencies and the parameters have been described approximately correctly, and provided further that the sensitivity investigation of the model over the possible parameter range shows no abnormal behavior.

This observation is important for the simulation of fuzzy systems: exact solutions cannot be expected, but a qualitatively correct description of dynamic behavior is probable. In decision-making, however, it is precisely the dynamic behavior that is of particular interest.

Development of the Behavioral Model

The successive steps in the development of a simulation model differ little from case to case. They are mentioned here merely for completeness, in the order in which they were carried out:

Collection of verbal information
Acquisition of statistical and other data
More in-depth information through interviews
Establishment of a data base
Determination of the interrelationships (network diagram)
Formulation of the system structure with identification of stocks, flows, auxiliary variables, etc.
Identification of parameters
Determination of the dependencies between variables
Programming
Trial runs and debugging
Coarse calibration
Qualitative validation and experiments across the full parameter range and possible initial conditions
Quantitative validation through statistical, historical, or concurrently obtained data
Simulation of reality
Investigation of various courses of action
Finding optimal courses of action

In general, the later steps will necessitate minor or major modifications of earlier steps and the acquisition of additional information.

Variables, Parameters, Dependencies

From the outset, an effort was made to capture all influencing variables as completely as possible. For this purpose, (fictitious) case records were first drawn up, beginning in the final years of secondary school and ending with graduation. In these records, an attempt was made to capture all factors and processes that could have even the slightest influence on student behavior during these years. These records were reviewed and supplemented by others to ensure that no influences had been overlooked.

Using the records, detailed lists of all factors, influences, variables, and parameters were then compiled. Each entry was then examined individually and thoroughly in order to eliminate obviously non-existent influences immediately, to combine synonymous entries (motivation, drive, aspiration, etc.) and opposites (enthusiasm/frustration) into a single variable each, or to split others (frustration due to financial pressure, grade pressure, or educational gap). From the cleaned-up list, the variables, constant parameters, and functional dependencies between variables were then identified. The designations introduced here correspond to those in the computing program and the diagrams. A detailed description of the complete project can be found in [10].

It should be noted that the simulation was developed for American higher-education conditions, which in some respects differ considerably from those in Germany.

The following main variables were identified and incorporated into the simulation:

Grade discrepancy PD (between actual and desired grade-point average)
Grade pressure P
Learning motivation AM
Learning performance without distraction UP
Actual learning performance AP
Achieved learning education AA
Grade-point average GPA
Relevant education RA
Desired educational activity outside the curriculum DE
Actual educational activity outside the curriculum AE
Achieved education outside the curriculum PA
Total achieved education TA
Learning objective function EG
Educational discrepancy ED
Frustration due to educational discrepancy FED
Frustration due to grade pressure FP
Frustration due to financial pressure FINFRUS
Total frustration F
Available funds BALANCE
Financial pressure FINPRS
Income from part-time work and summer work PARTJOB, SUMJOB, EARNING
Support from parents or others SUPPORT, AID
Scholarships SKOLR, SCHOL
Loans LOAN, DEBT
Expenditure (living costs and fees) LIVING, FEES, COST

The properties of the individual student are described by a larger number of parameters:

Grade target PG
Educational objective EDFAC
Self-motivation CAMS
Aptitude SATVM
Distraction CAPX
Weekly hours CUC
Frustration threshold FRUSTHR
Educational discrepancy threshold EDTHR

The following parameters describe the financial situation of the student:

Savings SAVINGS
Allowance/quarter CHECK
Net income from summer work SUMMER
Income from part-time work/week EARN
Income from loans/week LOANC
Income from scholarships/week SKOLSHP
Living costs/week LIVING
Fees/quarter FEEC

The institution itself is described by the following parameters:

Institutional motivation TAMI
Institutional performance effect TUPI
Curriculum relevance ratio TFRAC
Extra-curricular educational climate ENVIR

Perhaps the most important components of the simulation are the functional dependencies between variables. Almost all of these dependencies are functions of the personal properties of the student and should ideally be determined individually through psychological testing. (Such tests do not appear to exist as yet, but can probably be devised in most cases.) Brief reflection shows that these dependencies must in almost all cases be nonlinear. Since the relevant psychological data are not yet available, the various dependencies were estimated and used unchanged for all student types. The principal dependencies were:

Pressure due to grade discrepancy TP
Learning motivation through grade pressure TAMP
Motivational loss through frustration CAMP
Undistracted learning performance through motivation TUPM
Undistracted learning performance through aptitude UPA
Learning performance loss through extra-curricular educational activity CAPE
Learning performance loss through part-time work APDROP
Desired extra-curricular educational activity due to educational discrepancy TDE
Decrease in extra-curricular educational activity due to grade pressure TPRES
Decrease in extra-curricular educational activity due to frustration TFRUS
Educational frustration due to educational discrepancy TFED
Readiness to drop out TREADY

As an example of the assumed functional relationships, Figure 1 shows the dependence of learning motivation AMP on grade pressure AP; the other dependencies were determined by similar reasoning and can be taken from the attached program. Here 100% grade pressure corresponds to a grade-point discrepancy of 1 point. In the grading system considered here, 4 points corresponds to grade “A” (excellent), 3 points to “B” (good), 2 points to “C” (satisfactory), 1 point to “D” (poor), 0 points to “F” (fail).

The shape of the function AMP over P proved to be particularly critical; it had to be brought into its present form during the calibration process in order to achieve realistic results. When grade pressure rises to 50%, motivation simultaneously rises steeply to 100%. With a further increase in grade pressure, motivation remains unchanged at its maximum value, only to fall steeply back to zero as soon as grade pressure becomes too strong and the student gives up. When academic performance is better than expected (negative grade pressure), motivation becomes only slightly negative.

System Structure

The development of the system structure consists essentially in connecting the variables in a meaningful way, distinguishing between auxiliary variables and flow and stock variables. Even for a relatively simple system such as the present one, the structure becomes very complex. Only a greatly simplified schematic diagram will therefore be discussed here. (Figure 2 contains the sectors that describe the behavioral portion. The financial portion appears in Figure 3.) Circles denote auxiliary variables, boxes represent an integration (i.e., a combination of flow and stock variables). Smaller boxes with a bar denote delay elements.

The behavioral portion consists of four interconnected sectors: the learning performance sector P–AM–AP–AA–GPA–PD–P; the education sector RA–TA–ED–AE–PA–TA; the frustration sector FP–ED–FINFRUS–F; and the decision sector FRUSDEC–EDDEC–GPADEC–FINDECDEC. The financial sector consists of the main variables LIVING, FEES, PARTJOB, SUMJOB, LOAN, SKOLR, SUPPORT, and BALANCE.

The learning performance sector P–AM–AP–AA–GPA–PD–P constitutes the most important feedback loop of the system. The student perceives a grade discrepancy PD between the grade-point average GPA and the grade target PG. From this arises a corresponding grade pressure P and a corresponding learning motivation AM. This motivation is in some cases reduced by frustration F or increased by enthusiasm (–F). As a result of motivation AM, a certain learning performance AP arises, which further depends on personal parameters, on part-time work, and on other activities outside the curriculum. Integration of learning performance AP over time leads to a learning education AA, measured in units of (grade points × time). The current grade-point average GPA follows by division by time. Time is counted in weeks, with 12 weeks per quarter, three quarters per term, and four terms in four academic years. The simulation therefore runs over 144 weeks.

The education sector RA–TA–ED–AE–PA–TA would play only a minor role if the education provided through the curriculum (in the learning performance sector) were to coincide with the educational objectives of the student. Generally this is not the case, and only a certain fraction FRAC of the curriculum material is perceived as relevant. This results (in the student’s perception) in a relevant learning education RA. This relevant learning education RA combines with personal education PA (which arises from extra-curricular educational activities AE) to form total education TA. The student continuously monitors the development of total education TA and compares it with the educational objective EDFAC. In general, the student will perceive an educational discrepancy ED. After a certain delay, the student will then attempt to acquire additional education outside the curriculum through additional educational activity AE. The actual level of extra-curricular educational performance is, however, determined by grade pressure P and by the level of frustration F.

The frustration sector FP–ED–FINFRUS–F combines the frustration FP arising from persistent grade pressure with the financial frustration FINFRUS and the frustration FED that results from persistent (smoothed) educational discrepancy ED.

In the decision sector FRUSDEC–EDDEC–GPADEC–FINDECDEC, the respective magnitudes of various key variables that determine the dropout decision (frustration F, educational discrepancy ED, grade-point average GPA, account balance BALANCE) are compared with prescribed threshold values (different for different students). The student drops out when these threshold values are exceeded. Frustration threshold and educational discrepancy threshold are personal parameters and vary from student to student. A time-dependent function READY describes readiness to drop out. It depends on the term in which the student is enrolled. While it is lowest in the first and last year,

[Pages 55–72: Student Behavior Simulation Model — Results and Conclusions]

Financial Sector

In the financial sector (Fig. 3), income (from part-time work PART JOB, summer work SUMJOB, loans LOAN, scholarships SKOLR, and parental support SUPPORT) and expenditures (living costs LIVING, fees FEES) are compiled. From these, the available funds BALANCE and total income and total expenditures are calculated (total costs COST, total earnings EARNINGS, total debt DEBT, total scholarship income SCHOL, and total [parental] support AID). In addition, this sector determines whether scholarships or loans can be obtained on the basis of the grade-point average. If the student takes on a part-time job (as soon as his balance BALANCE falls below a minimum), a corresponding drop in his academic performance (APDROP) follows.

The programmed system structure is more complex than is apparent from the simple diagram. It is not useful to discuss it in detail here. A partial example may suffice. Fig. 4 shows the academic performance sector.

The discussion is restricted to the subsector AMS, TAMI, AM, AMF in the center of the figure, which is to be read as follows: The auxiliary variable “learning motivation AM” is calculated from motivation due to grade pressure (AMP), the student’s self-motivation (AMS), motivation through the institution TAMI (which is present as a table function in order to account for differing motivation in different years of study), and a motivation drop due to frustration AMF. Learning motivation AM then serves as an input for the calculation of the next auxiliary variable UPM (undistracted academic performance). The exact relationships follow from the computation program, which was programmed in DYNAMO (see appendix).

With the system structure available and translated into a computation program, the prerequisites for simulation are established. What remains is the description of the individual student and the institution through the corresponding parameters.

Simulations

The calibration, qualitative verification (validation), and subsequent simulations of the model were all carried out with the same 5 student and 3 institution profiles. These profiles spanned the entire possible range of types (see Fig. 5).

Abilities ranged from “highly gifted” to “poorly gifted”; the educational goal could consist of maintaining a certain grade-point average in order to be able to graduate, or of acquiring as much education as possible without regard to the grade-point average. Some students were financially worry-free, while others had considerable difficulty obtaining the required funds. The drop-out thresholds for frustration and educational discrepancy differed depending on the educational goal.

Three institution types were examined: an “excellent,” an “average,” and a “poor” institution. Significant differences existed in the motivation of students by the institution, in guidance toward special achievement, in the relevance fraction of the curriculum, and in the educational climate outside the curriculum.

From the combination of student and institution types, 15 simulation runs each resulted (totaling 1 minute on an IBM 360/75). The results of these runs were intuitively compared with reality. From these calibration runs, some — mostly minor — changes to parameters and functional relationships resulted.

It should also be noted that all necessary initial values for the simulation can be determined with high certainty; the sole exception is the student’s initial grade-point expectation IGPA. This point was therefore examined separately (with IGPA = 0 to 4). Larger deviations resulted only during the first year of study. Thereafter, almost identical results were obtained. These simulations appeared to largely duplicate the adaptation problems of the student in the first year of study.

Fig. 6 and Fig. 7 show the results of one simulation run (an “average” student D in an “average” institution). The upper curves show educational discrepancy ED, grade-point average GPA, and academic performance AP. The educational discrepancy changes little and remains at approximately 40%. Academic performance declines slowly; sharp drops occur at the end of each term, where the student has run out of money and must take on part-time work, which limits his academic performance. Despite these oscillations, the student can maintain a nearly constant grade-point average of approximately 2.4 (4 = A = best performance, 0 = F = worst performance). The step character of the GPA curve results from the determination of this average after each quarter.

The middle curves show the various educational components. With uniform educational growth the curves would be linear. If the student obtained all his education through the prescribed lecture curriculum, and if all of this education were considered relevant by him, a total education of 100% would result at the end of the course of study. In the present case, however, a substantial educational discrepancy ED exists, and the student attempts to cover it at least partially through education outside the curriculum.

The lower curves show the frustration components from the financial situation, the educational discrepancy (FED), and from ongoing grade pressure (FP), as well as the grade pressure P. While frustration due to educational discrepancy remains approximately constant, financial frustration increases continuously due to the poor financial situation. Thereby total frustration also rises, and premature dropout for this reason would be possible if the frustration threshold were correspondingly low.

The financial situation is depicted in the curves in Fig. 7. The student begins his studies with initial savings and parental support. This money is slowly consumed by living costs and tuition fees. Before the end of each term he must take on part-time work in order to avoid debt; in addition, he works during the summer. The curves show the current balance BALANCE, total costs COST, total earnings from [parental] support, and total earnings from work.

From the large number of variables printed by the computation program, academic performance AP, grade-point average GPA, total education TA, and total frustration F appear to be the most important. These received special attention in the subsequent investigations.

The diagram in Fig. 8 shows an overview of the 15 simulation cases used to calibrate the model. The results correspond to intuitive expectations. They cannot be discussed in detail here.

Further Investigations

After the model calibration had produced simulation runs that appeared at least intuitively correct, the model was employed for more systematic investigation of individual factors. For this purpose, the circumstances of the average student were improved to the point where financial worries no longer arose. Individual parameters were then changed one at a time, in order to examine their influence on the simulation run:

Student ability SATVM
Grade goal PG
Educational goal EDFAC
Relevance fraction of the curriculum FRAC
Extracurricular educational climate ENVIR

It would also go too far to discuss the results in detail here; they will be summarized at the end. Results again emerged that coincide with factual observations or intuitive insights, thereby reinforcing confidence in the model. With this backing, the effects of differing curriculum design and different fee structures were then examined in two further steps.

Influence of curriculum design: A student will learn best and most willingly when his lectures and exercises appear relevant to his educational goals. It is, however, clear that this educational ideal can only be realized to a certain degree, since certain societal goals or requirements (general studies, broad education, organizational obstacles, shortage of teaching staff or teaching resources) stand in the way of one-hundred-percent fulfillment. Under these circumstances, the question arises as to what the optimal distribution of relevance across the curriculum over the study period should look like, under the assumption that a given amount of subject matter — relevant and not relevant to the student — is to be conveyed.

As an example, suppose that a given body of course material, distributed over the four years of study, is perceived by the student overall as two-thirds relevant. Suppose further that the same course material, with the same overall relevance fraction of FRAC = 0.67, can be offered in three different ways:

constant relevance fraction 0.67;
increasing relevance fraction (linear increase from 0.33 to 1.0);
decreasing relevance fraction (linear decrease from 1.0 to 0.33).

Expressed practically, this would approximately mean: (1) constant mixture of general and specialized (for the student relevant) education; (2) general education first, specialization later; (3) specialization first, general education later. The question: which approach will produce better results? This question is intuitively very difficult to answer with any certainty.

Fig. 9 shows the results of a corresponding simulation (student C with financial difficulties at the end of the term). In the case of increasing relevance, academic performance does not differ substantially from that for constant relevance. Academic performance is, however, substantially higher in the case of decreasing relevance over the period of the first three years of study. The final grade-point average is correspondingly higher. Even larger differences emerge in the distribution of frustration; the curriculum with increasing relevance shows high frustration from the outset, while the curriculum with decreasing relevance maintains enthusiasm for at least the first two and a half years.

From this simulation it is to be concluded that the dropout rate could probably be substantially reduced by the introduction of relevant subject matter in already early-specialized curricula (problem-oriented, project-oriented, or career-oriented study programs). Later, the course material would then have to become broader and wider. From pedagogical observations it is to be concluded that a majority of students will seek out the broadening themselves, whereby the relevance fraction would rise above the assumed figure and the results would be further improved.

Influence of fee structure: The concept of “financial difficulties” ranks first as a reason for dropout at American institutions of higher education. Tuition fees are charged at all (public and private) institutions of higher education in the USA (except community colleges). They can range from several hundred to several thousand dollars per year.

At the University of California, a fee of 225 dollars per quarter is charged of California residents. Compared to living costs (approximately $2,000/year) and state subsidies for university operations (likewise approximately $2,000/year), the sum of $675/year is comparatively small, yet it is nonetheless the source of bitter complaints.

Fig. 10 shows how the academic performance and frustration of the average student C would change if the tuition fee were eliminated. The final grade-point average GPA would increase considerably, and the strong frustration — caused mostly by financial concerns — would turn into enthusiasm. It is to be expected that this measure could also considerably reduce the dropout rate. In this case as well, only a very uncertain statement can be obtained through intuitive judgment.

Overview of Simulation Results

The diagram in Fig. 11 summarizes the results of the various simulations very broadly. Positive effects are indicated by a plus sign, negative effects by a minus sign, and insignificant effects by a zero. Since a high degree of frustration or low performance or high educational discrepancy can lead to premature dropout, it is to be assumed that dropout rates can be reduced by the following factors:

high quality of the institution
high student ability
high relevance fraction of the curriculum
project-, problem-, or career-oriented course structure (temporally decreasing relevance fraction of the curriculum)
good financial support
elimination of tuition fees

On the other hand, a high grade goal and a high educational goal of the student increase his chances of dropping out due to higher frustration. These results may appear trivial, yet they seem at least to indicate that the model produces “reasonable” results and can probably be meaningfully employed in addressing a range of questions. (It should be noted that the model in its present form is tailored to American conditions.)

Conclusion

The detailed verbal description of the behavior of students in American four-year institutions of higher education has led to an explicit structural model of student behavior, to the quantification of parameters and functional dependencies, and to the numerical simulation of the temporal behavior of a number of “typical” students in “typical” institutions. In addition, the influences of certain parameters were examined in detail, and the consequences of certain curriculum designs and certain fee structures were traced.

The results of a sensitivity analysis over the entire range of parameters for student and institution appear to confirm the qualitative validity of the model: all results were reasonable and no aberrant results were observed. It is therefore to be assumed that the model at least qualitatively simulates reality correctly, and that it can be used as a decision-support tool. The model is to be regarded only as a first, possibly naive, step into largely unexplored new territory; improvements will have to follow. In any event, the results probably justify the conclusion that computer-aided simulation in the domain of human behavior can produce valuable and serious results, even though input data can often be quantified only through estimates.

Bibliography

A. W. Astin, College Dropouts: A National Profile. American Council on Education, ACE Research Reports, Vol. 7, No. 1, February 1972 (Washington, D.C.).
J. M. Dutton, W. H. Starbuck, Computer Simulation of Human Behavior. John Wiley, New York 1971.
H. Guetzkow, P. Kotler, R. L. Schultz, Simulation in Social and Administrative Science — Overviews and Case-Examples. Prentice-Hall, Inc., Englewood Cliffs, New Jersey, 1972.
M. J. Shapiro, The House and the Federal Role: A Computer Simulation of Roll-Call Voting. American Political Science Review, 62, June 1968, 495–517.
A. E. Amstutz, Development, Validation, and Implementation of Computerized Microanalytic Simulations of Market Behavior. In D. B. Hertz and J. Malese (eds.), Proceedings of the Fourth International Conference on Operational Research. Wiley-Interscience, New York, N.Y., 1966.
E. B. Roberts, D. I. Abrams, H. B. Weil, A Systems Study of Policy Formulation in a Vertically-Integrated Firm. Management Science, 14, August 1968, B-674–B-694.
A. I. Siegel, J. J. Wolf, Man-Machine Simulation Models: Psychosocial and Performance Interaction. Wiley-Interscience, New York, N.Y., 1969.
W. R. Fey, J. E. Knight, The Dynamics of Educational Institutions. In Proceedings of the 1971 Summer Computer Simulation Conference. Board of Simulation Conferences (BSC), 5975 Broadway, Denver, Colorado, 80216.
W. T. Newell, Simulation of Natural Resource Management and Sociological Systems: An Application of Industrial Dynamics. In Proceedings of the 1971 Summer Computer Simulation Conference. Board of Simulation Conferences (BSC), 5975 Broadway, Denver, Colorado 80216.
H. Bossel, Dynamic Simulation of the College Student and the Dropout Problem. University of California, Santa Barbara, UCSB-ME-72-3, 1972.

[page 50: figure only — Fig. 1: table function for “Motivation due to Grade Pressure” (AMP vs. grade pressure P, percent scale)]

[page 51: figure only — Fig. 2 / overall structure diagram: Behavioral Sector, showing relationships among academic performance drop (APDROP), relevance factor FRAC, academic achievement AA, educational goal EDFAC, and related variables]

[page 52: figure only — Fig. 3 / overall structure diagram: Financial Sector, showing LOAN, SKOLR, BALANCE, FINPRUS, COST, EARNINGS, DEBT, SCHOL, AID, and FINDEC nodes and their interconnections]

[page 53: figure only — Fig. 4 / Academic Performance Sector diagram, including subsector AMS, TAMI, AM, AMF]

[page 54: figure / table — Fig. 5: Student Types and Institution Types parameter table listing five student profiles (A–E) and three institution types with numerical parameter values for grade-point goal PG, education goal EDFAC, self-motivation CAMS, SAT score SATVM, extracurricular distraction CAPX, initial GPA IGPA, units per quarter CUC, initial savings SAVINGS, support per quarter CHECK, net summer income SUMMER, part-time job income EARN, loan income LOANC, scholarship income SKOLSHP, living expenses LIVING, quarterly fees, flags for part-time job JOB / loans LOANS / scholarship SKOLAR, frustration threshold FRCSTHR, and educational discrepancy threshold EDTHR; institution parameters include motivation due to institution TNMI, performance effect of institution TUPI, curriculum relevance fraction TFRAC, and extracurricular educational environment ENVIR]

[page 55: figure only — Fig. 6: simulation run curves for student D in an average institution — upper panel: educational discrepancy ED, grade-point average GPA, academic performance AP; middle panel: educational achievement components (total education TA, curriculum-acquired component ICA, extracurricular component); lower panel: frustration components (financial frustration, frustration due to educational discrepancy FED, frustration due to grade pressure FP) and grade pressure P, plotted over four academic years]

[page 56: figure only — Fig. 7: financial simulation curves for student D — BALANCE (quarterly financial balance), COST (total cost), AID (total parental support), EARNINGS (total work earnings), plotted over four academic years with dollar amounts on the vertical axis]

[page 57: figure / table — Fig. 8: Summary of Final Results for Five Different Students in Three Different Institutions — tabular overview of final grade-point average GPA (gp), total educational achievement TA (%), and total frustration F (%) for students A through E in excellent, average, and poor institutions]

[page 58: figure only — Fig. 9: simulation comparison of three curriculum relevance strategies (constant, increasing, decreasing FRAC) for student C — upper panel: academic performance AP and grade-point average GPA; middle panel: relevance fraction FRAC profiles over four terms; lower panel: frustration F for each strategy]

[page 59: figure only — Fig. 10: simulation comparison of $225/quarter fee vs. no fee for student C — upper panel: academic performance AP and grade-point average GPA with and without fee; lower panel: frustration F with and without fee, plotted over four terms; final grade-point average GPA indicated for each case]

[page 60: figure / table — Fig. 11: Major Conclusions table — rows: excellence of institution, high student ability SATVM, high grade-point goal PG, high educational goal EDFAC, good extracurricular educational possibilities ENVIR, high relevance fraction of curriculum FRAC, decreasing (vs. increasing) relevance fraction FRAC, better financial support CHECK, no fee ($225/quarter) FEEC; columns: effects on grade-point average GPA, total educational achievement TA, total frustration F; entries are +, 0, or −]

A Program System for the Simulation of Road Traffic Systems

Harald Ress, Institute for Informatics, University of Stuttgart

Short presentation at the Workshop on “Methodology of Computer-Aided Simulation,” 10–11 May 1973, Karlsruhe.

Page 73

Simulation is frequently employed in the investigation of complex traffic systems. This applies in particular to the assessment of the capacity of road traffic systems. One example is the study of local public transport systems, which are increasingly expected to resolve the daily traffic chaos in large cities. In order to be able to investigate the effects of expanded or new local transport means on traffic flow, it is first necessary to capture the traffic flow in arbitrary road networks. This is to be attempted in the following with the aid of simulation.

Early simulations dealt with traffic flow at individual intersections equipped with traffic signal systems. Subsequently, individual road stretches and road networks were investigated. The first studies originated in the United States. The objective of the earliest investigations was to represent traffic flow. Later work dealt, for example, with the optimization of traffic signal systems in specific urban areas. In Germany too, traffic engineers are applying simulation as an auxiliary tool to an increasing degree. Concrete questions arise, such as the effect of staggered working hours on traffic flow or the increase in throughput of a motorway network through the deployment of variable route-guidance signs.

Page 74

The great variety of questions leads to the creation of many simulation models, where similar problems are certainly often solved more than once. Most of these investigations have one thing in common: they observe the flow of traffic vehicles. Essential features in these systems are the divergence or convergence of traffic streams and the obstruction of traffic streams either by a traffic signal installation, a police officer, or by another traffic stream. For these reasons, the goal is to develop a traffic model with which the majority of road traffic problems can be investigated.

A road traffic network always consists of several subsystems of the same type. Examples are an intersection with a traffic signal installation, an intersection with traffic signs, or road segments connecting intersections. It is therefore possible to describe a traffic network by means of suitable subsystems. Similarly, the traffic flow in the individual subsystems can be described. These considerations lead to a simulation model that is assembled in a modular fashion from partial models. The model is to be constructed in such a way that individual building blocks (partial models) can be readily exchanged. This makes it possible to respond to the specific requirements of a traffic engineer.

In contrast to many simulations in the traffic domain, an event-driven simulation is employed here in order to keep computation time as short as possible. The investigation of extensive traffic networks with the aid of a period-oriented simulation, as is commonly used, appears to be very time-consuming.

Page 75

Each individual building block of the model represents a road segment and is realized by a queuing system with one server per lane. The length of a road segment determines the storage space of such a system; each partial model can therefore accommodate only a finite number of motor vehicles. Under heavy traffic conditions this may under certain circumstances lead to blocking effects in the overall system, which can readily be taken into account in the model. The service times at a server depend on the green phase of a traffic light, on the gap between successive vehicles in the priority traffic stream, or on the instructions of a police officer.

For a road network with traffic signal installations, the division into subsystems is to be illustrated. The individual subsystems here are road segments in one direction of travel between two intersections. At the beginning of each segment there is a traffic light. [In the figure,] the subsystems are drawn in for a road. Each subsystem can encompass multiple lanes; lane changes are possible.

[page 75: figure — schematic diagram of a road network divided into partial subsystems, with traffic lights at the start of each segment, numbered sections and direction arrows]

Page 76

The movement of vehicles in the partial models is represented uniformly. When a vehicle enters the system it is moved from subsystem to subsystem. The advance of vehicles within the individual road segments proceeds against the direction of travel. Accordingly, the individual building blocks are activated. In the example, the sequence of segments is therefore 1, 2, 3 and 6, 5, 4 respectively.

The activation of the individual partial models is governed by the respective signal phases. Each individual partial model is activated when the traffic light assigned to it switches to “green.” The movement of vehicles is interrupted at the latest when the end of the next red phase is reached. The next activation of the partial model thus takes place at the latest after one complete cycle. This “advance time” of a partial model is, however, also co-determined by the preceding partial model. Under normal conditions, vehicles cannot advance in time for longer than the vehicles in the preceding road segment.

Further simple subsystems are road segments with a lane reduction or with a lane expansion. In the first case, two vehicle streams merge — for example by the zipper method — and in the other case a vehicle stream splits into two new vehicle streams.

Page 77

These queues also have a server — for example a traffic light.

The merging of two traffic streams also occurs at the approach to an expressway or motorway. Here the service time for a vehicle at the server of the waiting stream is determined by the gaps in the main stream. The vehicles of the waiting stream are inserted into the main stream at the merging point in accordance with these gaps.

The model is intended to allow both microscopic and macroscopic investigation. In microscopic simulation, individual vehicles are tracked and moved from partial model to partial model. Exact account can therefore be kept of each vehicle and its path through the system can be followed. In macroscopic simulation, only traffic streams as a whole are considered; tracking of an individual vehicle is then no longer possible. Here, only statements are made, for example about the speed of the traffic stream and about the length of this traffic stream. At an intersection with a signal installation it must then be checked, among other things, what fraction of a stream can pass through the intersection on “green.” It is clear that a macroscopic investigation contributes substantially to shortening computation time.

Influence of Model Structure on Solution Effort in Dynamic Electrical Networks

W. Jentsch

Page 78

1. Introduction

A mathematical model of an object system to be simulated can generally be formed in various ways, even when the descriptions of the object system do not differ in accuracy. Such equally accurate, i.e. mathematically equivalent, descriptions yield the same “true” solution.

In numerical solution, such mathematically equivalent models can behave quite differently with respect to the permissible integration step size, the computational effort required to evaluate the differential equation, and the computability of all system quantities of interest. These differences lead to different solution effort.

This influence on solution effort is to be examined here using the example of dynamic electrical networks. It is most pronounced in the inductive partial network with nonlinear inductances.

In the following, resistive-inductive networks are therefore treated.

Page 79

2. Mathematical Models of a Resistive-Inductive Network According to the Loop-Current and Loop-Flux Methods

2.1 Structure of the Models

The mathematical models of a resistive-inductive network considered here are based on the “loop–cutset method,” and the notation introduced in [1] is used.

Figure 1 shows the “normal circuit” of a resistive-inductive network in general, compact form. The network is assumed to contain no current sources; these are irrelevant to the generality of the model properties of interest here.

Three steps are taken to arrive at the two models of the resistive-inductive network to be discussed.

Figure 2 shows the block diagram of the mathematical model of the network — in 3 forms — whereby the inductive partial circuit I is described in compact form (cf. Figure 7 in [1]). The block diagram in Figure 2.1 describes the resistive partial circuit in detail. By compactly describing the feedback loop in the resistive partial circuit by means of the “cutset resistance matrix” given by

one obtains the block diagram of Figure 2.2. By introducing the “inductive-loop resistance matrix”

$$R_B = -F_{RQH} , \underline{l}L , \underline{G}{GL}$$

and the “inductive-loop equivalent source voltages”

$$\underline{Y}1^B = -\bigl(f{LV} + E_{LG}^B , \underline{u}{GR} \cdot R \cdot f{RV}\bigr) \cdot \hat{l}$$

the compact block diagram shown in Figure 2.3 is finally obtained.

Figure 3 shows the block diagrams of the mathematical models of the inductive partial circuit according to the loop-current method and the loop-flux method. In the loop-current method, the inductive loop currents are the state variables; the derivative vector $\dot{\underline{i}}_L$ is the solution of a linear system of equations into which, in the general case of nonlinear characteristics, the differential inductances $l_L = (\nu_L)^{-1}$ and $l_r$ enter:

$$I_B \cdot \dot{\underline{i}}_L = \underline{y}^*$$

$$I_B = l_L - F , l_r , l_{rn}$$ (2.1)

$I_B$ is the differential “loop inductance matrix.” In the loop-flux method, the loop fluxes $\underline{\Phi}_B$ are the state variables; the inductive loop currents $\underline{i}_L$ are obtained from these in the general case by solving the nonlinear system of equations

Page 80

obtained therefrom.

Figure 4 finally shows the block diagrams of the two mathematical models to be discussed. In the loop-current method — see Figure 4.1 — the solution of the linear system of equations is represented in the form

$$Y_B = (l_B)^{-1}$$

The dependence of the matrix $Y_B$ on the differential inductances $\underline{l}$, which in turn ultimately depend on $\underline{i}_L$, is described by a second feedback path. In the loop-flux method — see Figure 4.2 — only the one feedback path via $f_u$ is present, which is also present in the same form in the loop-current method.

2.2 Properties of the Models

Several properties of the two models according to Figure 4 are now considered that have a significant influence on the solution effort.

2.21 Eigenvalues of the Differential Equation System

The eigenvalues of the Jacobian matrix of the ODE system have a determining influence on the permissible integration step size.

In the loop-current method — see Figure 4.1 — the normal form of the ODE system is given by

$$\dot{\underline{i}}_L = Y_B(\underline{i}_L) \cdot (\underline{v}_B - R_B \cdot \underline{i}_L)$$ (4.1)

The associated Jacobian matrix is

$$A = \left[\frac{\partial \dot{i}_{L1}}{\partial \underline{i}L},; \frac{\partial \dot{i}{L2}}{\partial \underline{i}_L},; \ldots\right]$$ (4.2)

In the loop-flux method — see Figure 4.2 — the normal form of the ODE system is given by

$$\dot{\underline{\Phi}}_B = \underline{v}_B - R_B \cdot \underline{i}(\underline{\Phi}_B)$$

The associated Jacobian matrix is

$$A = \left[\frac{\partial f}{\partial \underline{\Phi}}\right] = -R_B \cdot Y^B$$ (5.2)

The term $-R_B Y^B$ corresponds to the term $-Y^B R_B$ in (4.2).

Page 81

The essential difference between the two Jacobian matrices according to (4.2) and (5.2) is the additional term in (4.2) caused by the second feedback path — see Figure 4.2. This leads to a substantial increase in eigenvalues (in absolute magnitude) when operating points on the magnetic characteristics of the inductances lie in regions of strong curvature.

The additional term in (4.2) does not appear with linear magnetic characteristics (i.e., with constant inductances). It can also be avoided with nonlinear magnetic characteristics by substituting piecewise-linear (polygon) characteristics; however, the breakpoints of the characteristics must then be “bracketed in,” i.e., intermediate steps must be inserted such that the crossing of the breakpoints occurs practically at a step time point.

2.22 Types of Equation Systems to be Solved

Both models require the solution of systems of equations.

In the loop-current method — see Figure 3.1 — only a linear system of equations (2.1) ever arises. With smooth nonlinear characteristics, i.e., with continuously changing differential inductances, it is advantageous to solve the system of equations in the form (2.1). With linear characteristics it is always advantageous, and with piecewise-linear characteristics it is often advantageous, to determine the matrix $Y_B = (l_B)^{-1}$ once and to compute $\underline{i}_L$ from (2.2).

In the loop-flux method — see Figure 3.2 — with nonlinear magnetic characteristics the nonlinear system of equations (3) must be solved — e.g., by Newton’s method. With piecewise-linear characteristics, a substantial reduction in computational effort can result, e.g., due to a smaller number of iterations in Newton’s method or through the application of a special method tailored to this case. In the case of linear characteristics, (3) becomes a linear system of equations.

2.23 Possibilities for Determining the Inductive Voltages

If only tree-branch inductances occur, determining the voltages across these is very simple; the inductive voltages equal the inductive loop voltages $\underline{u}^L_B$, see Figure 3.1. If co-tree-branch inductances also occur, the voltages across the individual inductances must be determined separately.

In the loop-current method this is relatively straightforward, see Figure 3.1. From the derivatives of the inductive co-tree-branch currents $\dot{\underline{i}}{Lr}$, the voltages at the tree-branch inductances follow via the (inductive loop) umlauf matrix $F{Lu}$. The voltages across the co-tree-branch inductances are then obtained by subtracting the resistive co-tree-branch voltages from the total co-tree-branch voltages.

Page 82

In the loop-flux method this is more difficult, see Figure 3.2. One possibility here is to differentiate the fluxes $\underline{\Phi}_L$ and $\underline{\Phi}_r$; this has two serious disadvantages: numerical differentiation yields only inaccurate or grossly incorrect results (at jumps of the inductive voltages), and the results are available only at a later time than the other quantities. These disadvantages can only be avoided by the additional effort of determining the inductive voltages using the loop-current procedure and computing them as in that method.

Page 83

3. Examples

Two simple resistive-inductive networks with nonlinear inductances are considered as examples. Simulation tests were carried out using the RK4 method with constant step size — apart from the “bracketing-in” steps.

3.0 Magnetic Characteristics

Figure 5 shows two magnetic characteristics used for the simulations to be discussed. Characteristic K1 is a smooth characteristic for which $\Phi$, $i$, $di/d\Phi$ can be given by relatively simple expressions as a function of $i$. Characteristic K2 is a simple piecewise-linear (polygon) characteristic that approximates smooth characteristic K1 quite well.

3.1 Example 1: Single-Phase Nonlinear Choke

3.11 Description of the Network

Figure 6.1 shows the simplest resistive-inductive network with a voltage source in the form of the “normal circuit.”

Figure 6.2 shows the associated block diagrams corresponding to the loop-current method and the loop-flux method. In the first case (-1), the ODE reads:

$$\dot{i} = \frac{1}{l_1}(v - R \cdot i) = f(t, i)$$ (6.1)

and the associated “Jacobian matrix”

$$|\hat{f}_i| = -\frac{1}{l_1}\left(R - \frac{1}{l_1^2} \cdot \frac{dl}{di}(v - Ri)\right)$$ (6.2)

In the second case (-2) the ODE applies:

$$\dot{\Phi} = v - R \cdot i(\Phi) = f(t, \Phi)$$

with the associated Jacobian.

3.12 Comparison of the Loop-Current and Loop-Flux Methods

3.121 Smooth Magnetic Characteristic

In the loop-current method the influence of the second term in (6.2) on the eigenvalue $f_i$ is strongly apparent in certain regions; it should be noted that the critical term involves not only the curvature of the magnetic characteristic, but also the inductive voltage $u_L = v - Ri$ as a factor. The variation of $f_i$ is plotted in

Page 84

Figure 6.3-1. The high peaks of $f_i$ lead to the situation that step size $h = 0.5,\text{ms}$ is still acceptable, while step size $h = 1,\text{ms}$ already leads to instability.

In the loop-flux method, the magnitude of the eigenvalue $f_\Phi$ remains below a substantially smaller bound. With step size $h = 2,\text{ms}$, which probably cannot be significantly exceeded for reasons of representation accuracy, one remains well below the stability limit.

3.122 Piecewise-Linear Characteristic

Replacing smooth characteristic K1 with the piecewise-linear characteristic yields advantages in computational effort for both methods with only a very small loss of accuracy.

In the loop-current method, step size $h = 2,\text{ms}$ can now be used, as in the loop-flux method, since $f_i$ here has its “natural value.” However, the breakpoints of the piecewise-linear characteristic must be “bracketed in,” since no jumps in the derivative $\dot{i}$ may occur within one integration step. For one half-period with a fixed base step size of $h = 2,\text{ms}$, a total of 11 steps are needed; this is substantially fewer than the 20 steps required for the smooth characteristic.

In the loop-flux method, even with step size $h = 2,\text{ms}$, the “bracketing-in” can be dispensed with, since the kinks in the characteristic produce only kinks (not jumps) in the derivative $\dot{\Phi}$. The advantage in terms of computational effort lies here in the simpler linear interpolation for obtaining $i$ from $\Phi$. With step size $2,\text{ms}$, only 5 steps are required for one half-period. The loop-flux method is therefore clearly superior in this example case at relatively large step sizes.

3.2 Example 2: Three-Phase Nonlinear Choke

3.21 Description of the Network

Figure 7.1 shows a simple three-phase resistive-inductive network with three voltage sources forming a symmetrical three-phase voltage system, in the form of the “normal circuit.”

Page 85

Figure 7.2 shows the associated block diagrams corresponding to the loop-current and loop-flux methods, in the style of the general Figure 4. The input vector $\underline{y}^B_u$ is given by

$$\underline{y}^B_u = \begin{bmatrix} v_1 - v_3 \ v_2 - v_3 \end{bmatrix}$$ (8)

The diagram in Figure 7.2-2 is intended to illustrate the nonlinear system of equations that must be solved in the loop-flux method in the case of smooth characteristic K1 (for all 3 inductances).

3.22 Comparison of the Loop-Current and Loop-Flux Methods

3.221 Smooth Magnetic Characteristic

In the loop-current method the second term in (4.2) again makes itself felt in the same way as in Example 1. Step size $h = 0.5,\text{ms}$ is still acceptable; step size $h = 1,\text{ms}$ leads to instability. Figure 7.3 shows the exact variation of the three currents, which is also very well approximated with $h = 0.5$.

In the loop-flux method, step size $h = 2,\text{ms}$ remains, as in Example 1, well below the stability limit. The larger permissible step size is, however, bought at the cost of considerable effort in solving the nonlinear system of equations (3).

3.222 Piecewise-Linear Characteristic

In the loop-current method, 8 “bracketings-in” are required in the first half-period; with a base step size of $h = 2,\text{ms}$, a total of 34 steps are therefore needed for one half-period. On the other hand, the effort of solving a nonlinear system of equations does not arise here.

In the loop-flux method, as in Example 1, step size $h = 2,\text{ms}$ is well below the stability limit and no “bracketing-in” of the breakpoints is required. The use of the piecewise-linear characteristic does lead to a noticeable reduction in the effort of solving the nonlinear system of equations (fewer iteration steps), but the remaining effort is still considerable.

References

[1] W. Jentsch: “Zur Aufstellung des mathematischen Modells eines dynamischen elektrischen Netzwerkes über den ‘normalen Baum’.” ETZ-A, to appear autumn 1973.

Page 86

[page 86: figure only — Figure 1: Normal circuit of a resistive-inductive network in general, compact form, showing resistive partial circuit R, inductive partial circuit I, voltage sources, and branch-variable notation]

Page 87

[page 87: figure only — Figure 2: Block diagrams of the mathematical model of a resistive-inductive network with compact description of the inductive partial circuit I (three forms 2.1, 2.2, 2.3)]

Page 88

[page 88: figure only — Figure 3: Block diagrams of the mathematical models of the inductive partial circuit according to the loop-current method (3.1) and the loop-flux method (3.2), showing state variables, feedback paths, and matrix operators]

Page 89

[page 89: figure only — Figure 4: Block diagrams of the mathematical models of a resistive-inductive network in compact form according to the loop-current method (4.1) and the loop-flux method (4.2)]

Page 90

[page 90: figure only — Figure 5: Magnetic characteristics K1 (smooth curve) and K2 (piecewise-linear approximation), showing flux Phi versus current i, with normalized axes; K1 reaches approximately 1.5 Wb at the plotted range]

2. Mathematical Models of a Resistive-Inductive Network Using the Loop-Current and Loop-Flux Methods

2.1 Structure of the Models

The discussion concerns mathematical models of a resistive-inductive network based on the “loop–cutset method,” using the notation introduced in [1].

The two models to be discussed are developed in three steps. Figure 2 shows the block diagram of the mathematical model of the network — in three forms — in which the inductive sub-circuit I is described compactly (cf. Figure 7 in [1]). The block diagram in Figure 2.1 describes the resistive sub-circuit in detail. By compactly describing the feedback loop in the resistive sub-circuit by means of the “cutset resistance matrix,” the block diagram of Figure 2.2 is obtained. By introducing the “inductance loop resistance matrix”

$$R_B = -F R_{QH}$$

and the “inductance loop equivalent source voltages”

$$y_1^B = -(f_{LV} + E_{LG} B_t \dot{G}_R R_f R_V) \cdot t$$

the compact block diagram shown in Figure 2.3 is finally obtained.

Figure 3 shows the block diagrams of the mathematical models of the inductive sub-circuit according to the loop-current and loop-flux methods. In the loop-current method, the inductive loop currents are the state variables; the vector $\dot{i}_L$ is the solution of a linear system of equations in which, in the general case of nonlinear characteristics, the differential inductances $l_L = (\dot{V}_L)^{-1}$ and $l_r$ appear:

$$\mathbf{l}_B \cdot \dot{i}_L = y_L^B$$

$$\mathbf{l}_B = l_L - F l_r l_r^T$$ (2.1)

$\mathbf{l}_B$ is the differential “loop inductance matrix.” In the loop-flux method, the loop fluxes $\psi_B$ are the state variables; the inductive loop currents $i_L$ are derived from these in the general nonlinear case by solving the nonlinear system of equations

[page 80: continued from above]

$$Y_B = (l_B)^{-1}$$

The dependence of the matrix $Y_B$ on the differential inductances $l$, which in turn ultimately depend on $i_L$, is described by a second feedback path. In the loop-flux method — see Figure 4.2 — only the one feedback path via $\psi_B$ is present, which also exists in the same form in the loop-current method.

2.2 Properties of the Models

The following discusses some properties of the two models according to Figure 4 that have a significant influence on the computational effort required.

2.21 Eigenvalues of the Differential Equation System

The eigenvalues of the Jacobian matrix of the ODE system have a determining influence on the permissible integration step size.

In the loop-current method — see Figure 4.1 — the normal form of the ODE system is given by

$$\dot{i}_L = Y^B(\cdot) \cdot (v^B - R^B \cdot i_L)$$ (4.1)

The corresponding Jacobian matrix is

$$A = \begin{bmatrix} \frac{\partial}{\partial i_{L1}} Y^B_{…} & \frac{\partial}{\partial i_{L2}} Y^B_{…} \end{bmatrix}$$ (4.2)

In the loop-flux method — see Figure 4.2 — the normal form of the ODE system is given by

$$\dot{\psi}_B = v^B - R^B \cdot i_L(\psi_B)$$

The corresponding Jacobian matrix is

$$A = \begin{bmatrix} \frac{\partial i_L}{\partial \psi_B} \end{bmatrix} \cdot (-R^B)$$

$$= -R^B_\psi \cdot Y^B$$ (5.2)

The term $-R^B_\psi Y^B$ corresponds to the term $-Y^B R^B$ in (4.2).

[page 81]

The essential difference between the two Jacobian matrices (4.2) and (5.2) is the additional term in (4.2) caused by the second feedback path — see Figure 4.2. This leads to a significant increase in the magnitudes of eigenvalues when operating points on the magnetic characteristics of the inductances lie in regions of strong curvature.

The additional term in (4.2) does not appear in the case of linear magnetic characteristics (i.e., constant inductances). It can also be avoided with nonlinear magnetic characteristics by using piecewise-linear (polygon) approximations instead; however, the breakpoints of the characteristics must then be “bracketed in,” meaning that intermediate steps must be inserted such that the crossing of breakpoints occurs practically at a step boundary.

2.22 Nature of the Systems of Equations to be Solved

Both models require systems of equations to be solved.

In the loop-current method — see Figure 3.1 — only a linear system of equations (2.1) always appears. With smooth nonlinear characteristics, i.e., with continuously changing differential inductances, it is advantageous to solve the system of equations in the form (2.1). With linear characteristics, it is always advantageous, and with piecewise-linear characteristics it is often advantageous, to precompute the inverse matrix $Y_B = (l_B)^{-1}$ and thereby determine $i_L$ according to (2.2).

In the loop-flux method — see Figure 3.2 — with nonlinear magnetic characteristics, the nonlinear system of equations (3) must be solved — e.g., by Newton’s method. With piecewise-linear characteristics, a significant reduction in computational effort can result, e.g., due to a smaller number of iterations with Newton’s method, or by applying a special method tailored to this case. In the case of linear characteristics, (3) reduces to a linear system of equations.

2.23 Possibilities for Determining the Inductive Voltages

When only co-tree-branch inductances occur, determining the voltages across them is very straightforward; the inductive voltages equal the inductive loop voltages $v_{LB}$, see Figure 3.1. When tree-branch inductances also occur, the voltages across the individual inductances must be determined separately.

In the loop-current method this is relatively straightforward, see Figure 3.1. From the derivatives of the inductive co-tree-branch currents $\dot{i}{Lr}$, the voltages across the tree-branch inductances follow. The voltages across the co-tree-branch inductances (inductive loop voltages) are finally obtained by subtraction of the voltages across the co-tree-branch resistances from the inductive loop voltages $v{LB}$.

[page 82]

In the loop-flux method this is more difficult, see Figure 3.2. One possibility here is to differentiate the fluxes $\psi_L$ and $\psi_r$; this has two serious drawbacks: numerical differentiation yields only inaccurate or grossly erroneous results (in the case of jumps in the inductive voltages), and the results are always available only at a later point in time than the other quantities. These drawbacks can only be avoided by the additional effort of determining the derivatives in the loop-current method and computing the inductive voltages as in that method.

[page 83]

3. Examples

Two simple resistive-inductive networks are considered as examples, whose inductances are nonlinear. Simulation tests were carried out using the RK4 method with constant step size — except for the “input In.”

3.0 Magnetic Characteristics

Figure 5 shows two magnetic characteristics used for the simulations to be discussed. Characteristic K1 is a smooth characteristic, for which $\psi$, $l$, $dl/di$ can be expressed by relatively simple expressions as functions of $i$. Characteristic K2 is a simple piecewise-linear (polygon) characteristic that approximates the smooth characteristic K1 quite well.

3.1 Example 1: Single-Phase Nonlinear Choke

3.11 Description of the Network

Figure 6.1 shows the simplest resistive-inductive network with a voltage source in the form of the “normal circuit.”

Figure 6.2 shows the corresponding block diagrams according to the loop-current method and the loop-flux method. In the first case (-1), the ODE is

$$\dot{i} = \frac{1}{l} (v - R \cdot i) = f(t, i)$$ (6.1)

and the corresponding “Jacobian matrix”

$$|f_i’| = -\frac{1}{l} R - \left(\frac{1}{l^2} \cdot \frac{dl}{di}\right) (v - Ri)$$ (6.2)

In the second case (-2), the ODE holds:

$$\dot{\psi} = v - R \cdot i(\psi) = f(t, \psi)$$

with

3.12 Comparison of the Loop-Current and Loop-Flux Methods

3.121 Smooth Magnetic Characteristic

In the loop-current method, the influence of the second term in (6.2) on the eigenvalue $f_i’$ is noticeably strong in certain regions; note that in the critical term, not only the curvature of the magnetic characteristic but also the inductive voltage $u_L = v - Ri$ enters as a factor. The variation of $f_i’$ is shown in

[page 84]

Figure 6.3-1. The high peaks of $f_i’$ result in the step size $h = 0.5\ \text{ms}$ still being permissible, while the step size $h = 1\ \text{ms}$ already leads to instability.

In the loop-flux method, the magnitude of the eigenvalue $f_\psi’$ remains below a significantly smaller bound. With the step size $h = 2\ \text{ms}$, which probably cannot be substantially exceeded for reasons of representational accuracy, the stability limit is comfortably undershot.

3.122 Piecewise-Linear Characteristic

Replacing the smooth characteristic K1 with the piecewise-linear characteristic yields advantages in computational effort for both methods with only a very small loss of accuracy.

In the loop-current method, the step size $h = 2\ \text{ms}$ can now be used — as in the loop-flux method — since $f_i’$ here has the “natural value.” However, the breakpoints of the piecewise-linear characteristic must be “bracketed in,” since no jumps in the derivative $\dot{i}$ may occur within an integration step. For one half-period with a fixed basic step size of $h = 2\ \text{ms}$, a total of 11 steps$^1$ are required; this is substantially fewer steps than for the smooth characteristic, which requires 20 steps.

In the loop-flux method, the “bracketing in” can be dispensed with even at the step size $h = 2\ \text{ms}$, since the kinks in the characteristic here produce only kinks (not jumps) in the derivative $\dot{\psi}$. The advantage with respect to computational effort lies here in the simpler linear interpolation for obtaining $i$ from $\psi$. Here, only 5 steps are required for one half-period at the step size of 2 ms. The loop-flux method is therefore clearly superior in this example for relatively large step sizes.

3.2 Example 2: Three-Phase Nonlinear Choke

3.21 Description of the Network

Figure 7.1 shows a simple three-phase resistive-inductive network with three voltage sources forming a symmetrical three-phase voltage system, in the form of the “normal circuit.”

$^1$ 5 steps for the basic step time points; 3 additional steps per breakpoint when “bracketing in” by interpolation (2 steps to obtain the interpolation polynomial, 1 step for the interpolated step to be inserted).

[page 85]

Figure 7.2 shows the corresponding block diagrams according to the loop-current and loop-flux methods in the style of the general Figure 4. The input vector $v_B^*$ is given by

$$v_B^* = \begin{bmatrix} v_1 - v_3 \ v_2 - v_3 \end{bmatrix}$$ (8)

The diagram in Figure 7.2-2 is intended to illustrate the nonlinear system of equations that must be solved in the loop-flux method for the case of smooth characteristic K1 (for all 3 inductances).

3.22 Comparison of the Loop-Current and Loop-Flux Methods

3.221 Smooth Magnetic Characteristic

In the loop-current method, the second term in (4.2) again makes itself felt in the same way as in Example 1. The step size $h = 0.5\ \text{ms}$ is still permissible; the step size $h = 1\ \text{ms}$ results in instability. Figure 7.3 shows the accurate waveforms of the three currents, which are also very well approximated with $h = 0.5$.

In the loop-flux method, the step size $h = 2\ \text{ms}$ remains, as in Example 1, well below the stability limit. The larger permissible step size is, however, purchased at the cost of considerable effort for solving the nonlinear system of equations (3).

3.222 Piecewise-Linear Characteristic

In the loop-current method, 8 “bracketings” are required in the first half-period; with a basic step size of $h = 2\ \text{ms}$, a total of 34 steps are then required for one half-period. The effort of solving a nonlinear system of equations does not arise here, however.

In the loop-flux method, the step size $h = 2\ \text{ms}$ is, as in Example 1, well below the stability limit and “bracketing in” of the breakpoints is not required. The use of the piecewise-linear characteristic does lead to a noticeable reduction in the effort of solving the nonlinear system of equations (fewer iteration steps), but the remaining effort is still considerable.

References

[1] W. Jentsch
”On the Formulation of the Mathematical Model of a Dynamic Electrical Network via the ‘Normal Tree’.” ETZ-A, to appear in Autumn 1973.

[page 86: figure only — Figure 1: Normal circuit of a resistive-inductive network in general, compact form]

[page 87: figure only — Figure 2: Block diagram of the mathematical model of a resistive-inductive network with compact description of the inductive sub-circuit I (forms 2.1, 2.2, 2.3)]

[page 88: figure only — Figure 3: Block diagrams of the mathematical models of the inductive sub-circuit according to the loop-current method (3.1) and loop-flux method (3.2)]

[page 89: figure only — Figure 4: Block diagrams of the mathematical models of a resistive-inductive network in compact form according to the loop-current method (4.1) and loop-flux method (4.2)]

[page 90: figure only — Figure 5: Magnetic characteristics — K1 smooth characteristic (solid line), K2 piecewise-linear characteristic (dashed line)]

[page 91: figure only — Figure 6: Example: single-phase nonlinear choke. 6.1 “Normal circuit”; 6.2 Block diagram (cases -1 and -2); 6.3 Time diagrams for: v = 311 V, R = 0.2 Ω, f = 50 Hz, magnetic characteristic K1. -1 Loop-current method, -2 Loop-flux method. Shows $f_i’$ and $f_\psi’$ eigenvalue magnitudes along with current i/A and voltage u/V waveforms over time t/ms.]

[page 92: figure only — Figure 7: Example: three-phase nonlinear choke. 7.1 “Normal circuit”; 7.2 Block diagram (-1 loop-current method, -2 loop-flux method); 7.3 Time diagrams. Parameters: v = 311 V, f = 50 Hz, Rv = 0.2 Ω, magnetic characteristic K1. Also shows a $\psi$–$i$ characteristic plot for the nonlinear equation system.]

[page 93: figure only — Figure 7.3: Three-phase current waveforms i/A over time t/ms, showing three sinusoidal phase currents with peak approximately ±300 A over a 20 ms period.]

Computer-Aided Simulation at VW: Tasks and Technical Solutions

Dipl.-Ing. D. Böge
Dr.-Ing. H. G. Siepmann
VW Wolfsburg

Driving simulators can — depending on the level of technical sophistication — convey to a driver an accurate sense of driving that extends into the limit range of vehicle behavior. The foundations for this are, on the one hand, an accurate theoretical model of the vehicle that encompasses the limit range, and on the other hand the precise reproduction of all computable impressions — sight, sound, acceleration forces — that act on the driver in a moving vehicle.

The advantages of such simulation facilities for use in automotive research and development lie in:

the ability to represent arbitrary, parametrically defined vehicles (reproduction of arbitrary vehicle behavior), and
the precise measurability of quantities that characterize driving behavior.

The principal tasks that can thereby be addressed are correspondingly:

the technical further development of an existing vehicle concept with a reduction in costly prototype construction;
the development of an optimal vehicle concept on the basis of series driving trials and statistical evaluation of the subjective and objective data and measurements concerning the driving behavior of test subjects on various simulated vehicle models.

[page 95]

(In April 1973 such a series study was carried out with a different objective, namely the ‘investigation of driver behavior under the influence of alcohol.’)

The technical means for conveying driving impressions is the driving simulator. In this case it consists of a cabin that can be moved hydraulically about three rotational axes.

The driver is tilted into a position such that the always-present force of gravity, in terms of direction, reproduces the total acceleration force as a function of the computed driving state.

A black-and-white monitor provides the correct visual impression for each observation point — including those off the road — and a quadrophonic system provides the sound impressions.

A torque motor is used for steering torque simulation. The controls and instruments correspond to those of a VW 412.

The technical means for representing the theoretical vehicle model (drivetrain, vehicle dynamics) under real-time conditions, which must supply the signals to drive the driving simulator, is currently an analog computing system from the firm HSI (three consoles SS 100, 300 operational amplifiers).

Further features of the analog computing system include:

card-programmed function generators,
digital potentiometers,
resolvers.

Despite special computing techniques (e.g., analog multiplexing for function representation), the many nonlinear relationships impose model simplifications.

[page 96]

Better support — in terms of improved modeling and support for test management — of the simulation is achieved by deploying additional digital capacity in conjunction with the analog computing system, as planned from July 1973 onward.

An IBM/7 system installed in close proximity to the analog computer then takes over the organization of data transfer between the two main components of the hybrid data processing setup: the already-mentioned analog computing system HSI-SS 100 and the multipurpose computer IBM/360-195 located approximately 3 km away.

Dipl. Ing. Volker Hecht

Topic area: Design and Implementation of Simulation Models

Subject: Uniform Programming of a Hybrid System at the Problem-Oriented Level for the Simulation of Real-Time Problems

1. Introduction

Although the simulation of many processes can also be carried out in real time on suitable digital computers, the use of a hybrid system — consisting of a digital and an analog computer — is frequently sensible, above all for reasons of cost. Only sufficiently fast, and therefore usually large, digital computers can be employed for solving real-time problems; whether such a large computer can also be adequately utilized at other times is, for many users, doubtful. A genuine alternative can be offered by the hybrid system, which manages with a considerably smaller digital computer while retaining the well-known advantages of the analog computer, such as:

parallel mode of operation
true integration
interchangeability with real components
1:1 correspondence between the analog model and the real system
close man–machine relationship

However, coupling an analog computer not only brings additional advantages but also introduces additional disadvantages that must be accepted. Specific analog-computer problems such as:

constructing the computing circuit and scaling

as well as a suitable partitioning of the problem between the two computers — which is a prerequisite for the meaningful use of a hybrid system — contribute to the fact that hybrid systems are almost exclusively tools for users with specialist knowledge. Only through joint programming of the hybrid system can new users be attracted, users who then need concern themselves with the coupled analog computer only in special cases — for example, fault conditions or specially requested situations. A prerequisite, however, is that the programming system is capable of relieving the user to a large extent of solving these special problems arising from the coupling and the characteristics of the analog computer.

2. The Simulation Language

Among the known language developments for the simulation of time-continuous systems, the CSSL languages (Continuous System Simulation Languages [1]) appear particularly suitable for programming the complete system as a hybrid source language. With this language, both the structure of a model and the run-time schema of the actual simulation can be described conveniently. An important characteristic of CSSL languages is the macro concept of modern assembly languages, since analog operators can be conveniently emulated in the form of macros. Because no subroutine branches are necessary, fast simulation execution is achieved. With the usual macro concepts, a macro call inserts a complete instruction sequence — designated by the macro name — at the corresponding point. The disadvantage is that faster simulation execution entails a higher memory requirement. By adding user-defined macros, the language can be extended arbitrarily for individual problems.

A simple example is the representation of a potentiometer (multiplication by a constant factor):

MACRO POT (OV = A, IV)
  OV = A * IV
END MACRO

In a macro, unlike in subroutines, relationships between variables are formulated rather than between numerical values. The output variables are obtained from the input variables through a linking rule defined within the macro. Macros therefore represent a suitable element for describing the structure of simulation models. How many times a macro is to be traversed cannot be inferred from the macro itself. On the analog computer, macros are processed in parallel, whereas on the digital computer processing is carried out in a quasi-parallel sequence.

The user also has the option of creating a personal macro library. This provides a programming aid analogous to subroutines in higher-level languages.

An important consideration in selecting a suitable source language is the requirement that the excellent dialog capabilities — as known from the analog computer — should remain available in appropriate cases.

The CSSL standards accommodate these considerations, since they contain language elements that allow the user to intervene directly during a simulation run. If these intervention possibilities are to be used for genuine dialog, a display is needed that immediately provides information about the current behavior of relevant system variables. These relationships can be presented clearly in the form of curves, for example on visual display units. Since display units for real-time simulations of fast processes no longer satisfy the extreme time requirements, the use of the analog computer’s oscilloscope suggests itself as an alternative.

The dialog capability — coupled with corresponding query statements — can be exploited to change various parameters of the analog partial model directly through potentiometer settings, without requiring special digital routines for this purpose.

A particular improvement in expressiveness is achieved through the possibility of language interfaces to procedural languages such as FORTRAN or PL/1. This means that the characteristics of a procedural language — for example FORTRAN — are substantially extended and tailored to the specific problem domain by adding problem-oriented operators (e.g., for integration), a problem-oriented syntax (e.g., user-defined macros), and organizational features (e.g., sorting). In addition to more complex matters such as logical conditions, input/output operations can also be advantageously described in the procedural language.

When choosing a CSSL-compatible language, the available translators are also an important consideration (see Section 4). The target language of the known translators is generally FORTRAN, i.e., from the program written in the source language, a valid FORTRAN program is generated. If the translator itself is also written in FORTRAN, then near machine independence is achieved.

3. The Programming System

In [2], four different language levels were introduced that are matched to the structures of a hybrid system (Fig. 3.1). Using these concepts, the problem partitioning mentioned above represents a translation from the hybrid source language into an allocated source language.

       Hybrid Source Language
               |
       Allocated Source Language
               |
       Hybrid Assembly Language
             /         \
    Digital Part    Analog Part Language
         |                  |
    Digital Part       Analog Part

Fig. 3.1: Language levels of the programming system

The difficulties of this translation can be circumvented by leaving the decision to the user as to how the problem is to be partitioned. In this case it is unavoidable that the user must possess at least a basic knowledge of how an analog computer operates. In a more comfortable programming system, this system partitioning should occur automatically, though special user requests should still be permitted.

In the partitioning strategy, various considerations must be taken into account. The final analog system portion may contain — in terms of type and number — only those computing elements that can be interconnected on the analog computer. Furthermore, the required system partitioning is guided by the objective of processing the largest possible portions of the overall simulation model on the analog computer.

This strategy is in contrast to other approaches, in which only a few interconnections are to be realized on the analog computer so that a simpler patching system suffices. However, if one considers that the transfer of data between analog and digital computer — and vice versa — always costs additional time, then the time saving gained through analog execution of the operations must at least compensate for this time loss.

If one uses the simple numerical Euler integration method as a reference in a time balance — for which two operations are required, namely multiplication by the step size and addition to the old value — then for the analog processing of a second-order differential equation with 2 non-zero coefficients the following time balance results: a total of 2 multiplications by a constant factor and 2 additions are needed, plus 2 multiplications and 2 additions to carry out the integrations.

Assuming that the integrand is already available on the digital computer, then on, for example, the TR 86 from Telefunken, in the most favorable case with fixed-point numbers approximately 42 µs per step are needed for digital integration.

If this integration is carried out on the analog computer instead, then the value of the integrand must be transferred from the digital computer to the analog computer. In return, the time for the digital computation of one integration step is saved — in the example, 2 multiplications and 2 additions. In this way the additional time required for a single data transfer can exactly be compensated.

In addition to these boundary conditions imposed by the system hardware, the digital and analog system portions resulting from the partitioning should, in their specific problem formulation, be matched to the characteristics of the individual computers.

Subsystems with high natural frequencies are preferably to be processed on the analog computer. The magnitude of the time constants during integration and a numerical instability of digital integration methods that is already known in advance should be taken into account here.

[page 127 continues from page 126]

For inverse functions, special computing units are partly defined or must be additionally inserted.

2.3 Input of Data

The data to be entered for SCALE is divided into operating data and problem data. The operating data provides information about the scope and course of the computation. The problem data includes, for example, initial values of the integrating blocks, problem coefficients, and function-generator tables. In the procedure KOEF (Fig. 4b), the problem parameters are read in and the coefficients of the block structure are computed.

Since the input of the problem structure and the data takes place separately, several runs can be performed without recompilation. In the process, SCALE stores the absolute maxima of the problem variables from all runs, so that the final setting values for the analog computer account for the variation of all problem data.

2.4 Integration of the Problem Equations

To determine the absolute maxima of the problem variables and to output a limited number of solution curves, the problem equations are integrated in unscaled form. SCALE converts the entered problem structure into a system of first-order differential equations in order then to perform a quasi-continuous integration. The integration is carried out with automatic step-size control, whose relative truncation error is determined by the user. The sampling of the maximum values and querying of the states of the logical variables take place after each integration step. Once the maximum values of all problem variables are known, the integration can be skipped by means of appropriate operating

[page 128]

data.

In many cases, the scaling of the problem variables is to be based on function scales or maximum values specified by the user. These function scales can be entered with the data. After integration, SCALE compares the computed function scales with the input function scales in order to verify whether the entered function scales satisfy the condition

|x_i|_max / M_i ≤ 1

If not, the scaling is performed using the computed values (cf. Section 2.5.2).

2.5 Output Routines

The following sections describe the output routines of SCALE.

2.5.1 Entered Data

For verification purposes, the entered operating data and problem data are printed out again.

2.5.2 Characteristic Parameters of the Problem Variables

In this section (Fig. 5), the following values are output in tabular form:

Symbolic variables
Type of computing element
Absolute problem maxima
Minimum function scales*)
Computed function scales
Analog maxima**)

*) In this field, the prescribed function scales, if available, were first read in and then overwritten as described in Section 2.4.

[page 129]

*) The scaling refers to the minimum function scales).

If a program is run with multiple data sets, the characteristic parameters are printed after each computation.

2.5.3 Patch List

The patch list, separated into analog and logical variables, contains all necessary patch connections for the analog computer (Fig. 6). The computing elements are assigned symbolic addresses that are equal to the index of the output variable. Subroutines are resolved into individual computing elements. In addition, the computing elements are assigned symbolic names, such as:

INTG — integrator
SUMM — summer
MULT — multiplier
+REF — positive reference (+1)
ANDG — AND gate

The designation of the coefficient potentiometers follows from their use:

ICPOT n — initial-value potentiometer of integrator n. (n is the symbolic address of the integrator)
INPOT n — input potentiometer of integrator n without problem coefficients. (n is the symbolic address of the integrator)
KOPOT i — coefficient potentiometer of the entered problem coefficient i.

Subroutines are indicated by the heading:

SUBR n name

where n is the symbolic address and name is the designation of the structural block. The patch connections follow thereafter.

[page 130]

2.5.4 Setting Values

The lists (Fig. 7) for the setting values of the coefficient potentiometers are divided into integrator potentiometers (INPOT, ICPOT) and problem coefficients (KOPOT). The table for the integrator potentiometers contains the following columns:

Symbolic address
Value of INPOT
Column for entering the actual address of the INPOT
Input factor of the integrator
Value of ICPOT
Column for entering the actual address of the ICPOT

For the problem coefficients, the following columns apply:

Symbolic address
Value of KOPOT
Column for entering the actual address of the KOPOT
Input factor
Value of the problem coefficient
Scaling factor

To vary the problem coefficients, the following equation is used:

(value of KOPOT) × (input factor) = (value of problem coefficient) × (scaling factor)

The computation of setting values is valid only for the patch list that was produced beforehand.

2.5.5 Static Test

By means of the static test, the problem programmed on the analog computer is checked for patching errors and defective computing elements. Integrators that have no initial values, or initial values that are too small, are assigned “favorable” values for the static test. For this reason, a list (Fig. 8) contains the values for the initial-value potentiometers (ICPOT) once more, with their algebraic signs.

[page 131]

The initial values assigned by SCALE are marked with *.

The following table (Fig. 8) lists, with correct sign, the output values of all computing elements and, for the integrators, the sum of the input variables without sign inversion. Analog and logical variables are listed separately.

2.5.6 Output of Solution Functions

For comparison of the digital and analog simulation (dynamic test), the user may select any variables to be output in tabular form or, if a line printer with 90 or more columns is available, each in a diagram (Fig. 9). For each function, 50 equidistant value pairs are specified. The diagram has approximately the format of 20 cm × 20 cm, corresponding to the display devices and X-Y plotters of analog computers.

3. Concluding Remarks

The modular structure of SCALE permits almost arbitrary extensions. For preparation of hybrid simulations, the data transfer via the coupling unit and the computations of the digital computer can be inserted.

SCALE contains no sorting routine for the resolution of algebraic loops, so that the memory requirement is kept as small as possible. It is intended to develop a separate sorting program. A formula translator similar to APSE appears problematic, since the selection of a block structure optimal for the user is difficult to specify.

[page 132]

The example described here requires approximately 15 K words of core memory. By imposing restrictions in the output routines, the core memory requirement can be reduced considerably. The computation time was approximately 150 seconds on an ICL 1907.

References

[1] EAI — Automatic Programming and Scaling of Equations. Report No. 472

[2] Rook, P.E. — Automated Compilation and Set-up of a Simulation on a Hybrid Computer using ACTRAN. Proceedings of the Informatics Seminar HYBRID SYSTEMS, University of Stuttgart, February 1972

[3] Elzas, M.S. — Present state of HIFIPS, a hybrid interactive formula interpreting programming system. Proc. of AICA Conference, Munich 1970

[4] Franklin, M.A., Strauss, J.C. — Automated programming of analog/hybrid computers — a review. Simulation, January 1972

[pages 133–144: continuation from prior sections of the document — note on source text]

Note: The pdftotext extraction for pages 127–144 (physical pages in this document) corresponds to pages numbered 127–132 in the document’s own printed page numbering (the PDF’s internal page count differs from the printed numbers). The text extracted above begins at printed page 127 and ends at printed page 132, which is the last page of text content in the extracted range. The PDF pages beyond that point in this range (133–144 by the document’s own printed numbering) correspond to figures and appendix material that was not rendered as text-layer content in the extraction; these appear to contain only diagrams, tables rendered as images, and figure illustrations without a searchable text layer in those leaf pages.

The sections translated above (pages 127–132 as printed) complete the article SCALE — a digital implementation aid for analog and hybrid simulations by D. Heppner, covering:

Section 2.3: Data input (problem and operating data, multi-run coefficient storage)
Section 2.4: Integration of problem equations (unscaled integration, automatic step-size control, user-prescribed function scales)
Section 2.5: Output routines:
- 2.5.1 Echo of entered data
- 2.5.2 Characteristic parameters / function scales table
- 2.5.3 Patch list (symbolic addresses, potentiometer designations, subroutine notation)
- 2.5.4 Setting values (INPOT / ICPOT / KOPOT tables, scaling equation)
- 2.5.5 Static test (check for patching and hardware errors, ICPOT initial-value list)
- 2.5.6 Solution function output (tabular and graphical, 50 equidistant points, 20 cm × 20 cm format)
Section 3: Concluding remarks (modular extensibility, no algebraic-loop sorter by design, memory ~15 K words, ~150 s on ICL 1907)
References [1]–[4]

[page 145: figure only — Fig. 9: Output of Functions (printer plot showing multiple waveforms as ASCII character art)]

The Simulation Programming System MUNICH

N. Tichler

1. Introduction

The intention underlying the MUNICH simulation programming system is to create a unified programming system for hybrid and/or digital simulation of time-continuous systems. In terms of hardware, this requires a fully automated hybrid computing installation and a digital computer of at least medium size; the programming-technical foundation is provided by CSSL.

2. The Autopatch

A critical point is the necessity of an autopatch — that is, an automatic wiring device for the analog portion of the hybrid system. Work on the design and construction of an autopatch has therefore begun as a first priority. It will be available within at most two months and will contain approximately 1,200 switches for an analog computer equipped with 80 computing components.

3. The MUNICH Programming System

A CSSL version serves as the higher-level simulation language; its precise specification will be established only after coordination with as many other parties interested in simulation problems as possible. (At present, work proceeds with a subset CSSL-M of CSSL; the translator for this was created manually and comprises approximately 3,000 FORTRAN statements.) The FORTRAN portions of a CSSL program and the DERIVATIVE SECTIONS that are to be realized digitally are translated into a FORTRAN program; the DERIVATIVE SECTIONS to be realized in analog form are translated into a simple, block-oriented simulation language, namely DARE II-M. (The CSSL translator will, moreover, perform automatic loop handling according to Stein-Mundstock.) A user may also create DARE II-M program sections directly. The DARE II-M sections generated by the translator are linked — either automatically or according to user specification — with the program sections executing on the digital portion.

[Page 146]

The “abstract” analog circuit diagram now available in DARE II-M form is scaled by digital simulation (the translator for this — essentially a special macro-processor — is already available). The “scaled” DARE II-M program serves as input to the autopatch software.

It is the responsibility of the autopatch software to produce the analog circuit diagram corresponding to the scaled DARE II-M program. An allocation algorithm assigns analog computing components to the DARE II-M blocks, and a routing algorithm finds non-blocking paths through the multi-stage switching matrices of the autopatch. Both algorithms — that is, the autopatch software as a whole — are on the verge of completion.

The parallel logic of the analog portion recedes somewhat into the background in the current considerations, since various directions of further technical development are conceivable in this area.

4. Summary

The work planned and partly already carried out aims at producing a simulation programming system in which the user can decide in the simplest possible way which program sections are to be realized in analog/hybrid form and which in digital form. A programming system of this kind becomes possible only if the technical prerequisites (autopatch) are created at the same time. The overall project is therefore being built up from the “bottom” level.

[Page 147]

Burkhardt, Gießler, Mathe — GMD/I 7

CSMP-I

An Interactive Simulation Programming System for the Simulation of Time-Continuous Systems

CSMP-I is a simulation programming system for the TR 440 computer and represents a further development of CSMP/360.

CSMP/360 is a program system for computing installations of the IBM/360 series with a minimum core-storage size of 128 K bytes. CSMP/360 belongs to the class of simulators for continuous systems; the CSMP simulation language is built on the procedural language FORTRAN and combines all the advantages of a block-oriented language with all the capabilities of FORTRAN, in particular for representing algebraic and logical relationships. Very complex systems (with up to 300 integrators) can be investigated, including those with time-dependent coefficients and arbitrary nonlinearities. The starting point may be either a block diagram or a system of ordinary differential equations.

The CSMP/360 simulation programming system consists essentially of the executive program, the translator, the simulator, and a library of predefined functional blocks. The translator reads in the problem description formulated in CSMP (for one model at a time), checks it for completeness and formal correctness, sorts the structural statements — by evaluating special processing statements that control translation — into an admissible computation sequence, and translates them into a FORTRAN subroutine UPDATE. Procedural sections, which are already coded in FORTRAN, are adopted unchanged. Parameters and processing statements that control the execution of the simulation and the output of results are stored on an external storage medium and subsequently evaluated by the simulator.

[Page 148]

The FORTRAN subroutine UPDATE generated by the translator, together with any further FORTRAN subroutines explicitly added by the user, is then compiled by the FORTRAN compiler and, in a linking pass, connected with the required CSMP functional blocks and with the programs containing the actual simulation algorithms — which are already available in compiled form — to form the simulator. The simulator takes charge of carrying out the actual simulation, that is, essentially the time-stepping, the integrations, and the output of results. The executive program, finally, manages the sequence of the individual phases described above and depicted graphically once more in Figure 1, with each phase overlaying the previous one in core storage. It consists of a core-resident part and the main programs of the CSMP translator and simulator.

Although CSMP/360 is a highly developed simulation programming system and possesses great flexibility with respect to individual extensions and modifications by the user, it is essentially lacking in three respects:

1. Interactive capability. CSMP/360 is conceived for pure batch operation and therefore offers no interactive capabilities whatsoever. Simulation, however, is an iterative technique that — in the phase of model validation as well as in the phase of simulation execution (for example in optimization problems) — requires a high degree of interaction. It is precisely the interactive capabilities that distinguish the analog computer from the digital computer. In addition to batch operation, which is justified for certain cases, interactive operation from display consoles (and, with restrictions, from teletype terminals) should therefore be possible.

2. Capability for building and managing user-defined macro libraries and for managing user-defined function libraries. CSMP/360 does give every user the possibility of defining additional functions of his own in the form of FORTRAN subroutines and of defining his own macros, thereby creating a vocabulary adapted to his

[Page 149]

[figure only — Fig. 1 (Bild 1): CSMP-I processing flow diagram showing: CSMP Input → CSMP Translator; CSMP Function Library; FORTRAN Library → FORTRAN Compiler → Linker → CSMP Simulator → Parameters and processing statements; Drawing file; Print listings]

[Page 150]

particular problem domain. However, this requires that the definitions always be explicitly part of the input to the model in which the associated function and macro calls appear. It is considerably more convenient to store tested functions and macros in libraries from which they can be automatically loaded as needed.

3. Capabilities for graphical output on plotters and display consoles. Convenient capabilities for graphical output are the necessary complement to interactive capability. Simulation results in curve form are easier to evaluate than result listings; in particular, the results of one simulation run or of several simulation runs — plotted together in a single curve diagram — can be compared directly.

These three capabilities have been realized in CSMP-I. In order to achieve interactive capability, the executive program was redesigned from scratch (see Figure 2); the translator, the simulator, and the library of predefined functional blocks were adopted from CSMP/360 with only minor modifications.

In interactive mode, intervention points are provided at the positions marked with * in Figure 2. Interactive mode is enabled by the executive program whenever CSMP-I has been started from a console in so-called conversational mode. *1 permits errors in the CSMP program detected by the translator to be corrected and the CSMP program to be retranslated. *2 provides the same possibility if the FORTRAN compiler has found further errors in the FORTRAN subroutine UPDATE. In *3, FORTRAN subroutines written by the user can be corrected and retranslated by the FORTRAN compiler. In *4, one can respond to an error detected by the linker (missing subroutine), add the subroutine, have it compiled by the FORTRAN compiler, and re-link.

[Page 151]

[figure only — Fig. 2 (Bild 2): CSMP-I interactive processing flow diagram, showing intervention points *0 through *8, with CSMP Input; Macro Library; CSMP-I Translator; CSMP Function Library; FORTRAN Library; FORTRAN Compiler; Linker; CSMP Simulator; Graphical output *8; Print listings; Drawing file]

[Page 152]

In *5 one can correct errors detected in parameters and processing statements. In *6 one can generate graphical output at will, or suppress outputs that were specified during program entry. In *7 one can suppress specified parameter studies and specify different ones. In *8 one can suppress the simulation of a further model that was already specified, and specify a different one.

*0 represents an entry point and makes it possible to bypass the translation phase and work with a FORTRAN subroutine UPDATE already generated in a previous translation.

Macro definitions are copied — on request by a specially written macro pre-processor, before translation — from the CSMP program into the user’s own macro library or extracted from it. A macro definition in a CSMP program that is to be entered into the macro library is identified for this purpose by a ’+’ in column 6. A macro definition is inserted into a CSMP program when a formal macro call with a ’+’ in column 1 is recognized.

The macro library is a RAN file (direct access by record number), which is generally held in the LFD (long-term data store) or on exchangeable disk packs. Each macro definition occupies exactly one record. The individual macro definitions are accessed via a list containing all macro names; the position of a macro name in the list corresponds to the record position of the associated macro definition. The macro pre-processor does not check whether the actual parameters in the macro call match the formal parameters in the macro definition in type, number, and position; any discrepancies are, however, detected by the translator. With the help of two specially written TR 440 commands, the user can obtain information about the contents of his macro library and delete parts of it.

[Page 153]

User-defined function libraries are implemented using exclusively existing TR 440 operating-system components, since the TR 440 operating system permits defining a hierarchy of libraries containing link objects, which the linker searches for link objects according to the defined order of precedence.

In order to enable graphical output on a plotter (BENSON) and display screen (SIG 100), a program package GRAPHP was developed; the CSMP statement repertoire was extended by the processing statements GRAPH, GRAPHN, GRAPHF, and LABELG. The processing statements GRAPH and GRAPHN are used to specify in what manner a drawing file is to be processed at the end of each simulation run; during the simulation run, the values of the variables specified in a PREPARE statement were stored. GRAPHF identifies continuation cards, and LABELG allows text to be written over a diagram. Up to ten dependent variables from the same simulation run or from various preceding simulation runs can be plotted in a single diagram. Scaling can be performed — for all variables together according to the largest maximum and smallest minimum actually occurring, or according to a prescribed maximum and minimum; or for all or only some individually according to their actually occurring maxima and minima, or according to individually prescribed maxima and minima. The user can copy the drawing file into a personal LFD area and evaluate it at a later time using specially written TR 440 commands; this capability was particularly desirable for the compilation of diagrams for documentation and publications.

[Page 154]

CSMP-I has been operated by the group in the form described since the end of 1972. Experience to date has fully confirmed the expectation of more effective work with a simulation programming system, which motivated this development.

[Page 155]

Proposals for Extending DYNAMO

O. Kolbe — Institut A für Mechanik, Universität Stuttgart

1. Introduction

The language DYNAMO (dynamic models) was developed at MIT for the description and numerical simulation of dynamic systems. Since Forrester’s system philosophy /1/ served as the guiding principle in defining DYNAMO, social and economic systems can be formulated in DYNAMO in a particularly problem-appropriate manner, without the description of dynamic systems with other backgrounds being any less user-friendly as a result. The classification of system quantities according to Forrester into state, flow, and auxiliary variables, as well as into constants and tables, implicitly forces the user, during programming, to carry out the always-necessary structural and functional analysis of the system under investigation. A DYNAMO program contains, beyond a few control specifications for computation and output, only the components of the model. The relationships among the model quantities are specified either directly in the form of value assignments or generated via a DYNAMO-internal macro technique. During translation, the value assignments of a model are sorted and, during simulation, traversed according to a fixed algorithm. The initialization of a model is supported by DYNAMO in that the missing statements are generated from the model as far as possible.

Repetition runs with modified constant and table values or with altered output are prepared by the user via corresponding DYNAMO statements, which are interpreted by the translator. After such a recompilation, the simulation computation is restarted. The user thus prepares repetition runs manually — and in batch mode, before the first simulation run.

For detailed descriptions of existing DYNAMO implementations, the reader is referred to references /2/ and /3/.

[Page 156]

2. Extensions of the Language Scope

This section proposes several extensions of the language scope that the author considers useful for expanding the application domains of DYNAMO.

2.1 Connection of External Functions

Since DYNAMO is not a procedural language, branching (conditional expressions) must be realized using built-in functions. Since these functions quite simply cannot cover all conceivable cases directly, there is a need either to allow procedural inserts as in CSMP, or to enable the connection of user-written FORTRAN functions. The first solution is completely contrary to the concept of DYNAMO as a descriptive language and will not be discussed further here. The second possibility has been incorporated since recently (beginning of 1973) in the newest version of DYNAMO II /2/.

2.2 Connection of External Routines

In DYNAMO I, manipulation of variable arrays was possible (tabular recording of periodic signals or description of dead-time intervals). Although operations such as loading or shifting an array are inherently typical tasks for subroutines, DYNAMO I employed for these purposes a somewhat unfortunate notation in the form of symbolic value assignments. In DYNAMO II, array manipulations were therefore dropped for this reason. (The language version DYNAMO-TR4 of the author still retains these capabilities.)

Since array processing is on the one hand of some interest and on the other hand the DYNAMO I notation is rather obsolete, the only remedy here is an extension of the language repertoire to include the invocation of external routines. In doing so, the possibility must be provided that subroutine calls can be conditional on numerical events (clocked shifting of arrays). New statement types to be introduced are to specify when the (conditional) call of a FORTRAN or library procedure is due —

[Page 157]

namely, before or after the simulation computation, and at the beginning or end of each time step.

For a translator, the introduction of routines does not necessarily represent a significant complication, since the control of the simulation sequence already implicitly requires the invocation of routines according to this concept. In this way, DYNAMO models can access external data files (comparison with real data) or activate post-mortem operations (statistical evaluation of the simulation, launch of a user-written output program).

The introduction of routines into the language scope of DYNAMO must be completed by the declaration of externally computed variables, both for the sake of comprehensive error detection and for the sort algorithm.

Since in /2/ the possibility of side effects is not excluded when calling FORTRAN functions, in DYNAMO II the (unconditional) invocation of routines at each simulation step and before the simulation has already been covertly realized, albeit in a not very elegant manner.

2.3 Arrays of Variable Length

(section heading only; text continues on page 157 in the original)

[Page 158]

2.5 Flexible Termination Condition

To avoid unnecessary computation time, the termination of a simulation should also be triggerable by dynamic events. For this purpose it would suffice to declare some model quantities as criterion variables, whereby the sign change of one of these quantities triggers premature termination of the simulation. The previously used termination criterion of a prescribed simulation duration can be embedded in the more general principle via an intrinsic criterion quantity.

3. Extension of Model Control

As already indicated in the introduction, DYNAMO up to now processes a source file containing the model and any repetition runs in a “load-and-go” rhythm. However, the calibration of the parameters of a larger model in particular requires a large number of repetition runs with parameter values that only emerge from preceding runs. Moreover, the parameter variations frequently follow from algorithms such as the maximum-likelihood method (comparison of model behavior with real data from the past). There is therefore a natural need on the part of users to be able to activate a model formulated in DYNAMO from a program written in an algorithmic language such as FORTRAN. (The same need arises when DYNAMO-formulated operational models are to be integrated into a management information system as decision-support tools.)

For this purpose, a DYNAMO implementation in the computer must be constructed differently than before. One possibility is to let the actual compiler produce from the model a subroutine conforming to FORTRAN conventions, together with a reference data file; the subroutine carries the name of the model and can execute a simulation computation, while the data file contains declaration lists and output tables.

The previous execution of simulation runs can be realized by a control program that is launched by the compiler as its successor and alternately activates the subroutine and the

[Page 159]

recompiler. The subroutine can obtain the current values of the model constants for the computation and the current output tables from the associated data file in each case.

The activation of a model by a FORTRAN program can be accomplished simply by calling the corresponding, identically named subroutine, which has as parameters two arrays: through the first array the model is supplied with its flexible characteristic data, and in the second array the relevant simulation results are to be deposited.

On the DYNAMO side, a few new language elements are required for the connection to FORTRAN, in order to name the model and to identify its input and output quantities.

One can also consider generating standard framework programs for frequently occurring application cases by means of suitable control statements. Of particular interest here would be a static model optimization procedure for calibration, as well as a control program that varies several model constants in nested loops.

4. Example

To illustrate some of the DYNAMO extensions proposed above, the calibration of the coefficients α and β of the initial-value problem

x” − α·x’·(1 − x²) + β·x = 0, x(0) = 1, x’(0) = 0

is programmed. From the actual trajectory x(t), 201 equidistant measurements in the interval 0 ≤ t ≤ 2 are assumed to be known.

DYNAMO III Program

NAME    VAN DER POL-GLEICHUNG MIT UNBEKANNTEN KOEFFIZIENTEN
-NAME   VDPOL
PUT     ERROR PLTPER,ALFA,BETA,XM       } Identification of
GET     XM(201)                          } transfer quantities

PLOT    X=X,XSOLL=W/V=V

[Page 160]

L       X.K=X.J+DT*V.J
L       V.K=V.J-DT*(X.J+ALFA*V.J*(X.J*X.J-BETA))
N       X=1
N       V=0
L       ERROR.K=ERROR.J+DT*DIFF.J*DIFF.J*TRIGGER(TAKT)
N       ERROR=0
A       DIFF.K=X.K-XSOLL.K
A       XSOLL.K=XM(TIME.K/TAKT+1)
C       DT=0.001/LENGTH=2/TAKT=0.01
RUN ERGEBNISSE

FORTRAN Function

FUNCTION FEHLER(AB)
DIMENSION AB(2),UEBGB(205)
COMMON PLTPER,ALFA,BETA,XMLONG,XM(201),RES(1)
EQUIVALENCE (PLTPER,UEBGB(1))
ALFA=AB(1)
BETA=AB(2)
CALL VDPOL(UEBGB,RES)
FEHLER=RES(1)
RETURN
END

FORTRAN Main Program

DIMENSION AB(2)
COMMON PLTPER,ALFA,BETA,XMLONG,XM(201)
EXTERNAL FEHLER

! Read in XM and initial values for α and β.

XMLONG=201.0
PLTPER=0.0      ! (Freeze output)

... Call of a gradient method for FEHLER

PLTPER=0.01     ! (Activate output)
DUMMY=FEHLER(AB)
STOP
END

[Page 161]

Notes:

TRIGGER(TAKT) denotes the call of a planned, built-in DYNAMO macro that delivers the value 1 at intervals of TAKT and the value 0 otherwise.
As can be seen from the statement for XSOLL, the DYNAMO notation for an array element is modeled on FORTRAN.
When an array is passed between FORTRAN and DYNAMO, the current length of the array is additionally supplied (in the example XMLONG=201 before the array XM). This convention is necessary because of the arrays of variable length provided for.
The development of a pre-compiler based on FORTRAN for the sketched language version DYNAMO III is planned at the University of Stuttgart.

5. References

/1/ Forrester, J.W.: Principles of Systems, Wright-Allen Press, 1968.

/2/ Pugh, A.L. III: DYNAMO II User’s Manual, Fourth Edition, MIT Press, 1973.

/3/ Fuchs, G. and Kolbe, O.: Simulation dynamischer Systeme mit DYNAMO, lecture notes, Institut für Informatik der Universität Stuttgart, WS 1972/73.

[Page 162]

Research Group “Systems for Information Management” at the Institut für Informatik, Universität Stuttgart

Presenter: Stübel, G.

Participating persons: Beck, R.; Christ, P.; Falkenberg, E.; Schneider, H.-J.; Sedlacek, K.-D.; Stübel, G.

Topic: Heuristic Methods in the Simulation of Management Planning Models

Discussion contribution for the colloquium on “Methodology of Computer-Aided Simulation,” Karlsruhe, 10–11 May 1973

1. Introduction to the Overall Project

Montgomery and Urban begin their book Management Science in Marketing with a dialogue set in 1988. The core of this dialogue is the decision on the introduction of a new product. The future vision is that all decision alternatives in this dialogue are tested during the conversation with the aid of a simulation model. Only once the participants have obtained an overview of the implications of questions such as “What happens to a corporate goal, e.g. Return on Investment, if a particular measure — e.g. introductory advertising — is taken,” and have thus been able to assess the risk, do they take actual measures.

This motivation underlies the conception of the integrated corporate model, which is outlined briefly in the following.

The investigations are based on a problem situation from a company that, with 1,500 employees and a turnover of 84 million, belongs to the medium-sized enterprises.

The company produces sanitary fittings for bathrooms and sells these essentially to wholesale traders in the sanitary and electrical sectors.

[Page 151: figure only — CSMP-Input Macro Library / CSMP Translator block diagram (Bild 2)]

CSMP-I (continued)

In step *5, errors detected in parameter and processing statements can be corrected. In step *6, graphical output can be generated at will, or output specified during program entry can be suppressed. In step *7, specified parameter studies can be suppressed and others specified. In step *8, the simulation of a further, already specified model can be suppressed and a different one specified.

Step *0 represents an entry point and makes it possible to bypass the translation phase and work with a FORTRAN subroutine UPDATE that was already generated in a previous translation run.

Macro definitions are copied into or retrieved from the user’s own macro library before translation, on request, by a specially written macro preprocessor. A macro definition in a CSMP program that is to be entered into the macro library is marked for this purpose by a ’+’ in column 6. A macro definition is inserted into a CSMP program when a formal macro call with a ’+’ in column 1 is recognized.

The macro library is a RAN file (random access by record number) that resides in general in the LFD (long-term data storage) or on removable disk packs. Each macro definition occupies exactly one record. The individual macro definitions are accessed via a list that contains all macro names; the position of a macro name in the list corresponds to the record position of the associated macro definition. The macro preprocessor does not check whether the actual parameters in a macro call match the formal parameters in the macro definition in type, number, and position; any discrepancies are, however, detected by the translator. With the aid of two specially written TR 440 commands, the user can obtain information about the contents of the macro library and delete parts of it.

User-Defined Function Libraries

User-defined function libraries are implemented using exclusively existing TR 440 operating system components, since the TR 440 operating system makes it possible to define a hierarchy of libraries containing assembly objects, which the linker searches for assembly objects in the defined order of precedence.

To enable graphical output on a plotter (BENSON) and screen (SIG 100), a program package GRAPHP was developed; the CSMP statement inventory was extended by the processing statements GRAPH, GRAPHN, GRAPHF, and LABELG. The processing statements GRAPH and GRAPHN can be used to specify how a drawing file is to be evaluated at the end of each simulation run — a file into which the values of the variables specified in a PREPARE statement were stored during the simulation run. GRAPHF marks continuation cards, and LABELG allows text to be written over a diagram. Up to ten dependent variables from the same simulation run or from different preceding simulation runs can be plotted in one diagram. Scaling can be performed — for all variables jointly, according to the largest maximum and smallest minimum actually occurring, or according to a prescribed maximum and minimum; or for all or only some variables individually, according to their actually occurring maxima and minima, or according to individually prescribed maxima and minima. The user can copy the drawing file into a private LFD area and evaluate it later via specially written TR 440 commands; this is a facility that was particularly desirable for assembling diagrams for documentation and publications.

CSMP-I has been operated in the described form since the end of 1972. Experience to date has fully confirmed the expectation of more effective work with a simulation program system that motivated this development.

Proposals for Extending DYNAMO

O. Kolbe Institut A für Mechanik, Universität Stuttgart

1. Introduction

The language DYNAMO (dynamic models) was developed at MIT for the description and numerical simulation of dynamic systems. Because the system philosophy of Forrester /1/ served as the guiding principle in the definition of DYNAMO, social and economic systems can be formulated in DYNAMO in a particularly problem-close manner, without the description of dynamic systems with a different background being any less user-friendly. The classification of system quantities according to Forrester into state, flow, and auxiliary variables, as well as constants and tables, implicitly forces the user during programming to perform the always-necessary structural and functional analysis of the system under investigation. A DYNAMO program contains, in addition to a few specifications for controlling computation and output, only the components of the model. The linkages among the model quantities are either specified directly in the form of value assignments, or produced via a DYNAMO-internal macro facility. During translation, the value assignments of a model are sorted and, during simulation, traversed according to a fixed algorithm. The initialization of a model is supported by DYNAMO in that missing statements are generated from the model as far as possible.

Repetition runs with changed constant and table values, or with modified output, are prepared by the user through corresponding DYNAMO statements that are interpreted by the translator. After such a recompilation, the simulation computation is restarted. The user therefore prepares repetition runs manually — in batch operation, already before the first simulation run.

For detailed descriptions of existing DYNAMO implementations, the reader is referred to references /2/ and /3/.

2. Extensions to the Language Repertoire

This section proposes several extensions to the language repertoire that appear to the author to be meaningful for enlarging the fields of application of DYNAMO.

2.1 Connection of External Functions

Since DYNAMO is not a procedural language, branches (conditional expressions) must be realized with the aid of built-in functions. Since these functions simply cannot cover all conceivable cases directly, there is a need either to permit procedural inserts as in CSMP, or to enable the connection of user-written FORTRAN functions. The first solution runs completely counter to the concept of DYNAMO as a descriptive language and is not discussed further here. The second possibility has been included in the most recent version of DYNAMO II since recently (early 1973) /2/.

2.2 Connection of External Routines

In DYNAMO I, manipulation of variable arrays was possible (tabular recording of periodic signals or description of dead-time intervals). Although operations such as loading or shifting an array are in themselves typical tasks for routines, DYNAMO I used for these purposes a somewhat unfortunate notation in the form of symbolic value assignments. For this reason, array manipulation was dropped in DYNAMO II. (The language version DYNAMO-TR4 of the author still contains these capabilities.)

Since array processing is on the one hand of some interest and on the other hand the DYNAMO I notation is rather obsolete, only an extension of the language repertoire to include the invocation of external routines can provide a remedy here. Provision must be made for the possibility that subroutine calls can depend on numerical events (clocked shifting of arrays). By means of newly introduced statement types, it must be possible to specify when the (conditional) invocation of a FORTRAN or library procedure is due — namely before or after the simulation computation, or at the beginning or end of each time step.

For a translator, the introduction of routines does not necessarily represent a substantial complication, since the control of the simulation sequence already implicitly requires the invocation of routines according to this concept. For their part, DYNAMO models can in this way access external files (comparison with real data) or activate post-mortem operations (statistical evaluation of the simulation, start of a user-written output program).

The introduction of routines into the language repertoire of DYNAMO must be complemented by the declaration of the externally computed variables, for the sake of complete error checking and of the sort algorithm.

Since in /2/ the possibility of side effects cannot be excluded when calling FORTRAN functions, the (unconditional) invocation of routines at every simulation step and before the simulation is already realized in DYNAMO II in a concealed manner, albeit in a not very elegant way.

2.3 Variable-Length Arrays

If the type repertoire of DYNAMO is extended by variable-length arrays, queues and stacks can also be processed in DYNAMO with the aid of a suitable library of routines (traffic problems). The maximum length of such arrays must be specified in appropriate declaration statements.

2.4 Implicit Loops

By using free indices, computational statements for entire arrays of similar quantities can be written in a simplified notation at the DYNAMO level. (The introduction of implicit loops is planned by Pugh for a planned MIT version of DYNAMO III.)

2.5 Flexible Termination Condition

To avoid unnecessary computation time, the termination of a simulation should also be capable of being triggered by dynamic events. For this purpose it would suffice to declare certain model quantities as criterion variables, where a sign change in one of these quantities triggers premature termination of the simulation. The previously used termination criterion of a prescribed simulation duration can be embedded in the more general principle by means of an intrinsic criterion quantity.

3. Extension of Model Control

As already indicated in the introduction, DYNAMO up to now processes a source file containing the model and any repetition runs in a “load-and-go” rhythm. The calibration of the parameters of a larger model, however, requires a large number of repetition runs with parameter values that arise only from preceding runs. Moreover, the parameter variations frequently follow from algorithms such as the maximum-likelihood method (comparison of model behavior with real historical data). There is therefore a natural need on the part of users to be able to activate a model formulated in DYNAMO from a program written in an algorithmic language such as FORTRAN. (The same need arises when DYNAMO-formulated operational models are to be integrated into a Management Information System as decision aids.)

For this purpose, a DYNAMO implementation in the computer must be constructed differently from before. One possibility is to have the actual compiler produce from the model a subroutine according to FORTRAN conventions together with a reference file, where the subroutine bears the name of the model and can carry out a simulation computation, while the file contains declaration lists and output tables.

The previous handling of simulation runs can be realized by a control program that is started by the compiler as its successor and alternately activates the subroutine and the recompiler. The subroutine can in each case retrieve the current values of the model constants for computation and the current output tables from the associated file.

The activation of a model by a FORTRAN program can be accomplished simply by calling the corresponding, identically named subroutine, which has as parameters two arrays: the first array supplies the model with flexible characteristic data, and the second array stores the relevant simulation results.

On the DYNAMO side, a few new language elements are needed for connection to FORTRAN, in order to name the model and to designate the input and output quantities of the model.

Thought can also be given to generating standard framework programs for frequently occurring applications by means of appropriate control statements. Of particular interest here would be a static model optimization procedure for calibration, as well as a control program that varies several model constants in nested loops.

4. Example

To illustrate some of the DYNAMO extensions proposed above, the calibration of the coefficients α and β of the initial-value problem

ẍ − α·ẋ·(x²−β) + x = 0, x(0) = 1, ẋ(0) = 0

is programmed. From the actual trajectory x(t), 201 equidistant measurements in the interval 0 ≤ t ≤ 2 are assumed known.

DYNAMO III Program

NAME     VAN DER POL EQUATION WITH UNKNOWN COEFFICIENTS
PUT      VDPOL
GET T    ERROR PLTPER,ALFA,BETA,XM        } Designation of
         XM(201)                           } transfer quantities

PLOT  X=X,XSOLL=W/V=V

L  X.K=X.J+DT*V.J
L  V.K=V.J-DT*(X.J+ALFA*V.J*(X.J*X.J-BETA))
N  X=1
N  V=0
L  ERROR.K=ERROR.J+DT*DIFF.J*DIFF.J*TRIGGER(TAKT)
N  ERROR=0
A  DIFF.K=X.K-XSOLL.K
A  XSOLL.K=XM(TIME.K/TAKT+1)
C  DT=0.001/LENGTH=2/TAKT=0.01
RUN RESULTS

FORTRAN Function

FUNCTION FEHLER(AB)
DIMENSION AB(2),UEBGB(205)
COMMON PLTPER,ALFA,BETA,XMLONG,XM(201),RES(1)
EQUIVALENCE (PLTPER,UEBGB(1))
ALFA=AB(1)
BETA=AB(2)
CALL VDPOL(UEBGB,RES)
FEHLER=RES(1)
RETURN
END

FORTRAN Main Program

DIMENSION AB(2)
COMMON PLTPER,ALFA,BETA,XMLONG,XM(201)
EXTERNAL FEHLER

! Read XM and initial values for alpha and beta.

XMLONG=201.0
PLTPER=0.0          ! (freeze output)

... ! Call a gradient method for FEHLER

PLTPER=0.01         ! (activate output)
DUMMY=FEHLER(AB)
STOP
END

Notes

TRIGGER(TAKT) denotes the invocation of a planned, built-in DYNAMO macro that delivers the value 1 at intervals TAKT and the value 0 otherwise.
As can be seen from the statement for XSOLL, the DYNAMO notation for an array element is aligned with FORTRAN.
When an array is passed between FORTRAN and DYNAMO, the current length of the array is also supplied (in the example, XMLONG=201 before the array XM). This convention is necessary because of the variable-length arrays provided for.
Development of a precompiler based on FORTRAN for the outlined language version DYNAMO III is planned at the Universität Stuttgart.

5. References

/1/ Forrester, J.W.: Principles of Systems, Wright-Allen Press, 1968.

/2/ Pugh, A.L. III: DYNAMO II User’s Manual, Fourth Edition, MIT Press, 1973.

/3/ Fuchs, G. und Kolbe, O.: Simulation dynamischer Systeme mit DYNAMO, Lecture notes, Institut für Informatik der Universität Stuttgart, WS 1972/73.

Heuristic Methods in the Simulation of Management Planning Models

Research Group “Systems for Information Management” at the Institut für Informatik, Universität Stuttgart

Presenter: Stübel, G.

Participants: Beck, R.; Christ, P.; Falkenberg, E.; Schneider, H.-J.; Sedlacek, K.-D.; Stübel, G.

Discussion contribution for the workshop on “Methodology of Computer-Aided Simulation,” Karlsruhe, 10–11 May 1973

1. Introduction to the Overall Project

Montgomery and Urban begin their book Management Science in Marketing with a dialogue set in 1988. The core of this dialogue is the decision regarding the introduction of a new product. The future vision consists in the fact that all decision alternatives in this dialogue are tested with the aid of a simulation model during the conversation. Only after the participants have gained an overview of the consequences of questions such as “What happens to a corporate objective, e.g., Return on Investment, when a specific measure, e.g., introductory advertising, is taken” — and have thus been able to assess the risk — do they take actual measures.

This motivation underlies the conception of the overall corporate model that is to be briefly outlined below.

The investigations are based on the problem setting of a company with 1,500 employees and a turnover of 84 million [DM], which belongs to the medium-sized category of enterprises.

The company produces sanitary installations for bathrooms and sells these primarily to wholesale dealers in the sanitary and electrical trade.

Empirical data from this company are available for the initial values of the model. More important than the data, however, is knowledge of the mental models of the decision-makers and the quantities by which they orient themselves. Amstutz writes on this:

“Subjective evaluation is present whether or not an explicit model is established. However as a model is made explicit, the level of abstraction — the extent to which the model builder has reduced the situation to a limited and manageable number of factors — becomes more obvious.”

The simulation model thus represents the dynamic relationships among the quantities that the planner regards as essential, and can thereby provide statements about the consequences of decisions without already selecting optimal alternatives.

2. Design of the Overall Model

Since different model concepts come into play at the various levels of the corporate hierarchy, it is meaningful that this hierarchy is also reflected in the structure of the model.

For this purpose, the model is divided into elementary levels. These form — in accordance with the classification criteria of:

phase division (planning, implementation, control),
functional division (sales, production, …),
hierarchy (top, middle, operational level) —

a three-dimensional structure.

Particular emphasis is placed on the interfaces between the individual sub-models. These are designed so that only a few quantities that stand in a means–ends relationship — i.e., that simultaneously represent objective and control quantities — are passed to other subsystems (management by objectives).

3. Subsystems

The relative independence of the individual subsystems is achieved by initially basing communication with the environment and with dependent subsystems on functional assumptions about their behavior (1). These response functions are then replaced by further sub-models. Starting from the top model, the structures are thus refined progressively further (top-down approach).

4. Heuristics for Simulating Overall Corporate Events

In examining the decision tasks at hand, it can be established that these are predominantly incompletely formulated decision tasks. According to Klein /6/, these arise when:

(1) essential elements of the task formulation are unknown, or elude precise capture (especially in the form of numerical expressions), because the structures are too complex;

(2) the solution criterion is not unambiguously formulated, thereby allowing subjective, unverifiable valuations to determine whether a solution exists.

For solving such problems, Newell and Simon /8/ have especially concerned themselves with heuristic decision models. The term “heuristic principle” is understood here as “a rule that contributes to reducing, on average, the time expenditure for solving decision tasks” /6/.

This empirical-cognitive orientation proceeds from the research strategy that, in developing computer models for machine problem-solving, the mapping of human problem-solving behavior is a promising approach /2/. What is sought is a procedure that derives values for sub-objectives such as order intake and contribution margin from strategic superordinate objectives such as growth, success, and risk.

Although a number of investigations into corporate objectives and objective systems are available — particularly noteworthy here is E. Heinen: “Grundlagen betriebswirtschaftlicher Entscheidung — Das Zielsystem der Unternehmung” /5/ — a suitable mathematical definition of the concept “objective system” is lacking. This is, however, an indispensable prerequisite for formulating a general method for determining the measure that achieves all set objectives optimally.

The problem of optimal objective attainment lies in the fact that individual objectives of a system cannot be suboptimized independently of one another, because, as a consequence of competing objectives, an unwanted extremum occurs for one objective when another is optimized.

Example: The minimization of the objective “risk” can entail an unwanted minimization of “growth.”

A solution to the problem is possible if a specific subjective aspiration level is assigned to each objective, and beyond that, specific objectives are assigned a rank of importance or preference.

A mathematical definition of an objective system is now proposed here, which has proven meaningful for ordering objectives into a system and for a general solution procedure.

Definition: Let an indexed, disjoint family of sets (index set I) and a non-empty set of mappings f: D → Xⱼ, Xⱼ ∈ Z (j ∈ I) be given. For all sub-family collections, let exactly one set family be defined by (i ∈ I): Ωᵢ = {A | A contains from each set exactly one element x ∈ Xᵢ}.

A set Xᵢ ∈ Z is then called an objective set of 0th order if there exists a mapping f: Ω → Xⱼ, Xⱼ ∈ Z for which Xᵢ ∈ f(Ω) holds. A set Xⱼ ∈ Z is called an objective set of n-th order if there exists a mapping f: Ω → Xⱼ for which the following holds: there exists at least one set Xᵢ ∈ ξ (where ξ is the sub-family corresponding to Ω) that is an objective set of (n−1)-th order, and all other Xᵢ are exclusively objective sets of order less than (n−1).

If now for a condition of the following type is satisfied, then Z is called an objective system:

For every Xⱼ ∈ Z there exists at most one mapping f: Ω → Xⱼ.

Based on this definition, the following theorem can be proved:

Theorem: There exists a decomposition of an objective system into classes with objective sets of equal order.

A number of further definitions can moreover be formulated for concepts such as objective, base set, measure, optimizable objective system, admissible image, admissible solution, optimal solution, etc. Some of these definitions are already clear from the term itself, and so now only an algorithm for finding at least one admissible solution is to be outlined.

The algorithm is based on finding, successively in each class of objective sets of the system, the intersection of all domains of admissible images of the individual objective sets. Admissible images can be found with the aid of the Monte Carlo method. In this way, a domain of the base variables for admissible solutions is also determined with certainty 1. The specification of what percentage of all admissible solutions this domain is to encompass determines the number of computation runs, which is moreover proportional to the number of objective sets. It then only remains to find a suitable combination of values of the base variables that constitutes an admissible solution. At least one admissible solution can be found by the following procedure: after determining the bounds for two base variables, the coordinate origin is placed at the start of the domain of admissible values for the base variables. Then, under the assumption that the set of all admissible solutions forms a connected region, a straight line through the origin must hit at least one admissible solution (Figure 5).

Thus the success objective can be measured by means of the key figure

Return on Investment = Profit / Total Capital.

Possible target values are oriented toward the standard bank interest rate on capital, i.e., approximately 8%. Depending on corporate history, the aspiration level for Return on Investment thus lies above this value, in accordance with corporate strategy and subjective assessment. This objective can be achieved by means of the instrument of profit margin = Profit/Turnover, or by means of the instrument of asset turnover = Turnover/Total Capital.

The heuristic principle of the autonomization of means–ends components now implies new statements about the selection of the relevant field domain, i.e., new rules and independent statements are now made about the aspiration level of the sub-objectives.

The mapping of the sub-objectives is given by the multiplication of the two quantities:

Return on Investment = (Profit / Turnover) × (Turnover / Total Capital)

ROI = Profit Margin × Asset Turnover Frequency

With the aid of the program described above, which simulates the coordination problem among the individual corporate departments, all planned values of the elementary level “Planning in Top Management” are determined. In the dynamic model, which is structured according to the system dynamics method, measures are taken in accordance with deviations from given planned key figures that seek to improve the corresponding sub-objective. A corresponding decision rule in DYNAMO reads:

Sales Expenditures.KL = Planned Sales Expenditures.JK × (1 + q × Sales Deviation.JK)

where q is a subjective parameter. In accordance with a given response function /1/, the market responds correspondingly delayed (3rd-order delay) with a changed order intake.

[page 168: figure only — “The Environment of the Simulation Model” block diagram (Bild 4), showing Management/Decisions, Market, Corporate Events (Unternehmensgeschehen), Simulation Model, Hypothesis Bank, Methods Bank, Data Bank, and Decision Rules Bank interconnected]

[Page 181]

…test routines were developed that detect critical developments in time.

A key element of the present study is the heuristic development of strategies for assigning workpieces to the machining units from their input buffers and for controlling workpiece transport through the rotary tables at the branch points in the transport system. By changing the default positions of the rotary tables in System 1 (Figure 4) to follow the current dominant workpiece flow, the frequency of blockages in sub-areas of the system can be reduced, thereby achieving both a modest increase in the utilization rate of the machining units and a reduction in workpiece throughput times. Modifications to the roller conveyors — in particular to the input buffer A 1 (Figure 3) — lead to the system structure designated System 2 (Figure 4), with a utilization increase of 7% for the same workpiece spectrum. The flexibility of the system is not increased by this change, however.

System 3, in contrast to Systems 1 and 2, allows alternative and combined assignment strategies thanks to random access to workpieces on rotating input buffers. This structural change must, however, be reflected in a modified model CINCIN-02 by means of a new description of unit A1 (input buffer section). Alternating application of the strategies

“first come, first served” (FCFS) and “shortest operation time first” (SOT/KOZ)

depending on the load on the input buffer leads, for example, to an increase in utilization of more than 30% and to a corresponding increase in workpiece throughput compared to System 1. Modifications to the transport system produce system structures as shown in Figure 5, Systems 4–6. An increase in system flexibility makes system control and the exploitation of that flexibility more difficult. The advantages of interactive models lie — as experience in the course of this work has shown — in the fact that the interactive capability allows insight into the model process to be gained as a basis for developing and improving decision strategies and control algorithms

[Page 182]

for guiding real systems.

5. Summary

The problem addressed here proceeds from a reduction of the object domain to its technical aspect. The object domain is determined by the real environment in which a manufacturing system is to be deployed, and is therefore substantially shaped by economic, social, and psychological cause-and-effect relationships. Treating a manufacturing system as a purely technical construct limits the informational value of the simulation results with respect to this object domain, a limitation that must be consciously kept in mind.

The modelling process is traversed multiple times in any simulation approach — both during the model validation phase and in the further development of the model on the basis of a modified objective or a deepening of the analysis. The development of simulation languages with higher conceptual quality and, above all, their readiness for use on the computing equipment actually available can simplify this process — which is characterized by time-consuming programming effort and debugging — and create more room for the issues of the object domain.

In the context of the manufacturing system simulation considered here, the model process serves — beyond the generation of highly aggregated behavioral statements in the form of statistics — above all the purpose of recognizing, through the interactive capability with the model process, the behavior of complex systems in individual runs, so as to verify the logic of conceptual models and to reproduce that logic. For this purpose the model process must run before the eyes of the system analyst. Human–machine communication via display screens is a prerequisite that must be met by the development of appropriate simulation languages or extensions thereof.

[Page 183]

References

Opitz, H.: Wirtschaftlicher Einsatz numerisch gesteuerter Werkzeugmaschinen unter Berücksichtigung technologischer Aspekte [Economical Use of Numerically Controlled Machine Tools with Consideration of Technological Aspects], Fertigung und Betrieb 21 (1971) No. 9, pp. 531–539.
—: ROTA-F 125 NC System Niles, WMW-Export-Import, Prospekt Nr. 5917/1971.
Clementson, A. T.: Control and Simulation Language, Online-Seminars, The Hague, Jan. 1972.
Kiviat, P. J.: Development of Discrete Digital Simulation Languages, Simulation, Feb. 1972.
Reinhardt, A.: Simulation eines Fertigungsprozesses mit GASP [Simulation of a Manufacturing Process with GASP], TZ für prakt. Metallbearbeitung, Vol. 66 (1972), No. 2.
Kamp, A.-W. / Reinhardt, A.: Simulation von Systemen mit Werkzeugmaschinen [Simulation of Systems with Machine Tools], in Schöne, A. (Ed.): Simulation technischer Systeme [Simulation of Technical Systems], Carl Hanser Verlag (to appear Sept. 1973).

[Page 184: figure only]

Figure 1 caption (Bild 1): Manufacturing systems composed of interlinked numerically controlled machine tools — Simulation of time-discrete systems. A. Reinhardt. TU Berlin, Dept. 20, Automation, System Simulation and Process Control.

The figure shows:

Upper diagram: Plan of an automatic manufacturing system for gearbox housings, with a machining station including workpiece table, fixture, and workpiece. Key:
- a — horizontal or vertical machining station
- b — numerical control
- c — address setter
- d — address reader
- e — address converter
- f — loading station
- g — main conveyor
- h — cross conveyor
- i — rotary-table signal transmitter
- k — rotary table
- l — workpiece table
- m — washing station integrated into the manufacturing line
This is the Line System (CINCINNATI): 1 = central workpiece storage, 2 = loading, 3 = central control, 4 = clamping station / alignment, 5 = unclamping station / cleaning, 6 = satellite storage, 7 = tooling centre, 8 = tool transport trolley, 9 = tool presetting, 10 = tool racks; I … IX = storage rings.
Lower diagram: Star System (ROTA-F 125 NC)

[Page 185: figure only]

Figure 2 (Bild 2): Flow diagram of the model process

The diagram illustrates the structure of the GASP simulation cycle, divided into an Analyst Program Section and a GASP Program Section. Key steps:

SET: initialise GASP variables, set files via subroutine UPDATIN.
Main simulation loop with time-advance mechanism.
Protocol extension via subroutine OUTPUT.
Branching on conditions (yes/no).

Figure 3 (Bild 3): System model for NCMX = 7 machining units, structured into sub-systems and permanent units

Permanent units:

A1) Input buffer section
A2) Machining station
A3) Output buffer section
B1) Conveyor section
B2) Rotary table
C1) Storage section
C2) Unclamping device
C3) Finished-parts store
D1) Raw-parts store
D2) Clamping device

[Page 186: figure only]

Figure 4 (Bild 4): Structures of interlinked manufacturing systems 1–3

System 1: Single-direction traffic. Workpiece access according to FCFS. Equal conveyor section lengths in both main conveying directions and in the input buffers.
System 2: Single-direction traffic. Workpiece access according to FCFS. Load-dependent conveyor section and input buffer lengths.
System 3: Single-direction traffic. Random workpiece access. Input buffer utilization controllable via assignment strategies.

Figure 5 (Bild 5): Structures of interlinked manufacturing systems 4–6

System 4: Single-direction traffic on the main conveying route. Transport path shortening as a result of direction-dependent loading and unloading in input buffers. Access as in System 3.
System 5: Line system with one main conveying section and two-direction traffic via a transport vehicle. Access as in System 3.
System 6: Star system. Stacked storage rings with interlocked transport routes; machine-assigned transport systems. Workpiece access as in System 3.

Note: The PDF page numbering (document pages 169–172) preceding page 181 contains diagrams relating to an earlier contribution on corporate management models (hierarchical levels, optimisable objective systems, heuristic algorithms). Pages 173–180 contain the introductory sections (sections 1–4.4) of the Reinhardt paper on computer-aided simulation for manufacturing system structures, which form the context for the translated pages 181–186 above. Pages 187–198 of the document as requested are not present in the extracted text output — the document text layer ends at page 186 of the PDF (document page “–15–”). The remaining pages in the range 187–198 appear to be blank or contain only figures not captured by the text layer.

The Parameters σ_y and σ_z of the Equation

The parameters σ_y and σ_z of the equation were taken from experimental observations. A practical limitation of the equation was: no spatial variation of average wind speed and wind direction. The key requirement is the availability of a representative average wind field for the urban area under investigation.

It proved impractical to treat each individual source separately within the New York City area. All of these point sources were therefore combined into an area source with a uniform emission rate. The integrated plume formula was adopted in the model.

The equation in Figure 2 states that the total concentration from area sources represents the sum of the pollutant contributions of all point sources combined within a given area.

$$X_\text{TOTAL}(X,Y) = \sum_n X_n(\Delta_{nA}, X, Y)$$

where:

Δ_nA = average height of the area sources
X_n = contribution to pollutant concentration of each point source
A = area of the point sources

[page 200: figure only — Figure 2 diagram of area-source plume diffusion]

4. The Principles of the IBM PALO ALTO Diffusion Model

The computer program calculates the air pollution contributions from point sources and area sources independently of each other. The SO₂ pollution forecast covered an area of 1,600 square miles within the New York City region. Inversion weather conditions, which can occur at any time, are incorporated into the program as variables. The diffusion coefficients σ_y and σ_z were treated as functions of atmospheric stability, downwind distance, and terrain. Meteorologists had performed important preparatory work in this area. The program is based on the six stability classes defined by Pasquill¹⁾ and refined by more recent investigations (Figure 3).

¹⁾ Pasquill, F.: The estimation of the dispersion of windborne material, Meteorological Magazine, 90, 1961, pp. 33–49.

[page 201: figure only — Figure 2 full-page diagram: Diffusion of a Plume Originating from an Area Source]

Atmospheric Stability Classes

Key to Stability Classes

Surface Wind Speed (m/s)	Daytime Solar Radiation — Strong	Moderate	Slight	Night — Slightly Cloudy	Cloudy
< 2	A	A–B	B	—	—
2–3	A–B	B	C	E	F
3–5	B	B–C	C	D	E
5–6	C	C–D	D	D	D
> 6	C	D	D	D	D

The neutral class D should be assumed for overcast conditions during the day and at night.

Stability classes:

A — Extremely unstable
B — Moderately unstable
C — Slightly unstable
D — Neutral
E — Slightly stable
F — Moderately stable

[Figure 3: Graph of σ_y and σ_z (vertical and horizontal dispersion coefficients in meters) as a function of distance from the emission source (m), shown for all six stability classes on a log-log scale.]

5. The Computer Procedure

The computer program is written in FORTRAN IV (H) and requires 200 K (of core memory). The main program consists of four parts:

Analysis of the data from the emissions inventory
Analysis of the meteorological data
Calculation of the surface pollution concentration
Graphical output of the computed values

The analysis of the emissions inventory data includes, in addition to the area and point source data, their geographic positions, which are recorded in a coordinate system. This system is defined in the model as a rectangular coordinate system. The x-axis represents the east–west direction and the y-axis the north–south direction. The daily emission rate from area sources was determined by the following formula:

$$E_D = \frac{Y_1 \cdot Q_A}{365} + Y_2 \cdot \frac{DD \cdot Q_A}{TDD}$$

where:

E_D = daily emission rate of SO₂
Q_A = annual emission rate of SO₂
DD = difference between 65°F and the daily mean temperature when the latter is 65°F or below; otherwise DD = 0
TDD = climatological mean annual degree-day value
Y₁, Y₂ = proportionality factors for water heating and central heating; Y₁ + Y₂ = 1

The computer program calculates two-hour average emissions for point and area sources. The calculation was carried out for the time period from 0 to 24 hours.

[page 204]

The execution time for a two-hour simulation with 500 area sources was 15 seconds on a System/360 Model 91 and 5 minutes on a System/370 Model 145.

The computed values were output via an IBM 2250 display terminal.

6. The Results, Presented in the IBM Diffusion Model Film (16 mm)

The results obtained were presented as a system of isolines in order to illustrate graphically the frequency distribution of the pollutant concentration. The simulation results were subsequently compared with actual pollutant measurements. It was found that the deviation of the predicted results from the actually measured values was no greater than 15%.

An outstanding result.

Test and Measurement Facilities for a Simulation System for Investigating the Dynamic Behavior of Operating System Software

(continued from page 216)

Page 217

(Continuation of code example for the $TEST pseudo-instruction)

IF MODUS = 'T' THEN DO;
    PUT SKIP LIST('PERIODIC?:');
    GET LIST (ART);

    IF ART = 'PERIODIC' THEN DO;
        PUT SKIP LIST('GIB:PERIODE,TESTPHASE:');
        GET LIST(PERIODE, TESTPHASE);
        $INT(0,5,1,);
    END;
    ELSE DO;
        PUT SKIP LIST('GIB:STARTZEIT, TESTPHASE:');
        GET LIST(STARTZEIT, TESTPHASE);
        $INT(STARTZEIT,5,1);
    END;
END;
$IDLE; $0;

LAB(4):;   /+ end of simulation +/

$0  $STOP;

$0  LAB(5):;   /+ beginning of a test phase +/

$INT(TESTPHASE,6,1);

IF ART = 'PERIODIC' THEN DO;
    $INT(PERIODE,5,1);
END;
$TEST('T'); $IDLE; $0;

LAB(6):;   /+ end of the test phase +/

$TEST('P'); $IDLE;

The above example also demonstrates the use of another pseudo-instruction:

- $STOP

This instruction provides a means for the controlled termination of a simulation run by deleting all events in the event controller.

- $PR_DUMP

This last of the listed pseudo-instructions enables the output of the status contents of all processors in the

Page 218

system at any desired point in time, and likewise constitutes a valuable aid in debugging the models.

Summary

Using several examples from the field of operating system software simulation, it has been shown that a limited set of simulation primitives can cover a wide spectrum of applications. The implementation effort for these primitives is comparatively low and therefore often superior to an integrated solution (in simulation languages such as GPSS), which typically requires considerable effort and reduces simulation efficiency.

References

[1] Fleck, G., Nehmer, J. Simulation von Betriebssoftware auf einer virtuellen PL/1-Maschine [Simulation of Operating Software on a Virtual PL/1 Machine] Lecture Notes in Economics and Mathematical Systems 78 Springer Verlag, Berlin-Heidelberg-New York, 1972, pp. 253-262

[2] Rupp, M., Nehmer, J., Fleck, G., Hilse, D., Friehmelt, R. PLIM — Eine virtuelle PL/1-Maschine [PLIM — A Virtual PL/1 Machine] KFK 1712, Kernforschungszentrum Karlsruhe, May 1973

Page 219

[page 219: figure only]

Fig. 1 — Organization of the Simulation System

The figure shows the organizational structure of the complete simulation system. The upper half depicts the control structure, subdivided into three levels:

Event controller (Eventsteuerung)
Machine controller (Maschinensteuerung) — with “CALL MODELL” link
Model (Modell) — composed of System and Pseudo-instructions

Legend:

Dashed arrow: control data (Steuerdaten)
Dotted arrow: control flow (Kontrollfluss)
Open arrow: model creation (Modellerstellung)

The model creation path runs through: Source code → Macro Processor → PL/1 Compiler → Model

The virtual PL/1 machine (PLIM) comprises the event controller and machine controller together.

Fig. 2 — Schematic Organization of a Model under PLIM

The figure shows a box labeled “Model” containing:

Measurement object environment (Messobjektumgebung)
Measurement object (Messobjekt)
Monitor

Below the model box: n Processors (for the model) and 1 Processor (for the monitor), together constituting the “PLIM Hardware.”

Page 220

(MS-H 866 v)

Model Formation in the Context of the Simulation of Subscriber Systems

R. Isernhagen Philips Forschungslaboratorium Hamburg GmbH, 2 Hamburg 54

1. Introduction

The goal of the work reported here is to investigate various concepts and configuration alternatives for terminal systems using simplified models.

Figure 1 shows an example of such a terminal system — a so-called data-collection system. The configuration shown is composed of various types of modules: devices, adapters, and processor cores (CPUs).

[Figure 1: Configuration example for a terminal system (data-collection system)]

Key:

G_i: Devices (Geräte)
T_i: Adapters (Adapter)
R.K.: Processor cores (Rechnerkerne)

Page 221

(MS-H 866 v)

As an application area for such a system one might think, for example, of a wholesale enterprise. For each department — such as warehousing, accounting, or sales — an intelligent terminal is provided, consisting of a small computer and a number of input/output devices, with which the data-processing tasks arising in that department (such as inventory management, accounts-receivable bookkeeping, or invoicing) are handled. The entire complex of applications for a terminal system is referred to hereafter as the “application” (Applikation).

The purpose of model formation and the investigations to be carried out on the models is to make qualitative and quantitative statements about the behavior of the individual modules, about the interaction of various modules, and about the flow of information between the modules.

2. The Relationship Between Model and Object

The object — that is, the real system — is structured in many hierarchically graded levels; the interfaces between these levels are in each case “languages” or “instruction sets” (Figure 2).

In the models, by contrast, the entire hierarchical structure is ignored; instead, the configuration is described as it presents itself to the user. The result is the configuration model (Konfigurations-Modell).

For the implementation of the configuration model — one could also say for its realization — the simulation package

Page 222

(MS-H 866 V)

[page 222: figure only]

Fig. 2 — Representation of the Relationship Between a Computer System and Its Model

The figure is a two-column diagram. The left column represents the real object (a computer system); the right column represents the model. Both columns show matching hierarchical layers connected by equivalence arrows:

Real system (left column, top to bottom):

APPLICATION (in the form of programs)
Problem language
MACHINE LANGUAGE / MICROPROGRAMMING
Microcode language
MACHINE LANGUAGE / HARDWARE
Hardware-level language
HARDWARE (raw)

Model (right column, top to bottom):

APPLICATION MODEL
Application modelling language → AMOL
CONFIGURATION MODEL
Configuration modelling language → COMOL
BOMOL
SIMULATION PACKAGE → SAMO

(Note: The text layer for this page is garbled OCR from a diagram; the above description reconstructs the diagram’s content from context.)

SAMO is used. When applying this package, the individual modules of the configuration are each captured using a so-called Box Modelling Language (BOMOL), while the Connection Modelling Language (COMOL) replicates the interconnection network between the modules — that is, it defines the configuration.

Completely separate from the configuration model, there exists an application model that is to be derived from the user programs. The application model is processed by the configuration model, in analogy to the way in which the application is processed by the configuration in the real system. In the real system the interface between the two parts is in general a problem-oriented language such as COBOL; in the model, the corresponding language is called AMOL — Application

Page 223

(MS-H 866 V)

Modelling Language. The application model will not be discussed here for reasons of time; instead the configuration model will now be addressed.

3. The Configuration Model

The configuration model consists of the partial models for the individual modules — such as processor cores, devices, and adapters — and of a model of the interconnection network. The modelling of the various modules proceeds independently of one another. In the following, the procedure for model formation and the concept according to which the partial models are constructed will be sketched using the example of a processor core.

Three phases in model formation can be distinguished:

In the first phase, the requirements specification (Pflichtenheft) of the partial model is defined. It consists of a listing of all so-called elementary actions that the model is capable of executing. In the case of the processor core, one obtains, for example, approximately the list shown in Figure 3a.

[Figure 3a — Examples of elementary actions of a processor core]

(The figure lists handwritten/typed examples of elementary actions, including items such as:

Execute instruction
Find address
Read data
Handle interrupts
Write data
Handle I/O request
Process interrupt The exact text of the figure is partially illegible due to OCR artifacts.)

Page 224

(MS-H 866 V)

In the second phase, each elementary action is defined in more detail. This involves questions such as the encoding of information and the specification and description of parameters for the individual elementary actions.

In the third phase, the sequence in which these elementary actions are to be triggered is defined. This sequence is, of course, not rigid; it depends essentially on three influencing variables:

the elementary action currently being executed,
the information arriving from outside into the partial model,
the AMOL statement of the application model currently being processed.

The result of this phase can be represented very clearly by a state diagram, as indicated in Figure 3b.

[Figure 3b — Representation of the sequence of elementary actions by means of a state diagram]

Page 225

(MS-H 866 V)

The states represented as circles are assigned to the elementary actions (EA1 through EA7). It is apparent that, with regard to the sequence in which this graph is traversed, there are multiple possibilities from the perspective of each elementary action. The partial model is thus controlled by the application model, the environment, and the internal state. In automaton-theoretic terms, it therefore constitutes an extension of the Moore automaton.

Figure 4 shows the structural concept of the partial model for a processor core. It contains as its essential components:

a memory into which the relevant portion of the application model is loaded,
a list of elementary actions with all specifications established in phase 2 of the model formation process,
an action controller that manages the execution of the respective elementary action,
an action program in which the sequence of elementary actions as established in the state diagram is encoded.

Particular emphasis in the model formation concept sketched here is placed on modularity and flexibility: all essential parts of the model can be readily modified.

Page 226

(MS-H 866 V)

[page 226: figure only]

Fig. 4 — Concept for the Structure of the Partial Model: Processor Core

The figure shows the structural layout of the partial model. It contains the following labeled blocks:

AMOL PROGRAM (Memory for application model portion)
LIST OF ELEMENTARY ACTIONS (with their specifications)
ACTION CONTROLLER (Aktionssteuerung)
ACTION PROGRAM (Aktionsprogramm)

4. Status of the Work

The first preliminary investigations — in which smaller configurations, each consisting of one processor core and several devices, were modelled and simulated — have been completed. Currently, the model for the data-collection system sketched at the outset is being developed.

Page 227

(MS-H 866 V)

5. Concluding Remarks

If one attempts to identify the problems and difficulties that arise in model formation, three categories would be cited:

Definition of the interface between the configuration model and the application model, i.e., specification of the Application Modelling Language (AMOL), in order to obtain fixed boundary conditions for the development of configuration models.
The collection and organization of all information about the object to be simulated that is essential for model formation.
The abstraction process leading from the object to the model, which among other things involves a substantial reduction of information.

30.4.1973 / RI / br

Page 228

User-Friendliness in Simulation Technology

By Klaus Lagemann Communication from Philips Forschungslaboratorium Hamburg

1. Introduction

The increasingly complex system considerations accompanying each new computer family prompted the development management to engage with simulation technology in the design of new medium-range data-processing computers. The development management proceeded from the practical assumption that individual developers would naturally have to concern themselves primarily with the problems of the object being designed — the new computer — and that simulation technology would play merely the role of an investigative tool whose use would in principle be learned as a side matter, just as one is accustomed with, for example, the investigative tool “oscilloscope.” In reality, however, simulation technology proves to be a specialist craft; from the perspective of the development laboratory it appears to be, in fact, a specialist science remote from practical application.

For the research laboratory, the question therefore arose of how simulation technology as a development tool could be made more user-friendly. This gave rise to the simulation program package SAMO, which was initially installed on the Electrologica X8 computing system and subsequently also on the Control Data CD 6600. The following sections show how the SAMO package is shaped by the overriding requirement for user-friendliness and what experience has been gained with it so far.

2. Structure and Description of a Model in SAMO

The SAMO program package was already reported on on 12 April 1972 at the NTG specialist conference “Operating Systems” in Darmstadt, so that a summary will suffice here. The intended application domain — namely the simulation of computers — suggests describing the model of the object to be simulated as a system of black boxes and mutual interconnections —

Page 229

[page 229: figure only]

Fig. 1 — Model formation for the system structure of an object

The figure shows two parts:

a) The Model Plan

A diagram of four black-box types (type numbers: 431, 522, 625, 54). Instances of the same type are numbered consecutively. The diagram shows boxes labeled:

54.1, 54.2, 54.3, 54.4
522.1
625.1, 625.2

b) Description of the Connections in COMOL

Syntax for the basic form of a connection:

cr <Black-Box-Type-No.> . <Instance-No.> . <Output-No.> → <Black-Box-Type-No.> . <Instance-No.> . <Input-No.>

The complete interconnection network contains, in addition to the basic form, compound forms as well. The factoring rules used there are self-explanatory when compared with the model plan:

cr 431.1.2  →  522.1.2                  Basic form
cr 431.2.2  →  522.1.1 + 625.1.2        Branching, expressed by the plus sign
cr 431.3.2  →  625(1.2)1                Branching, with factoring of common numbers
cr 522.1.1  →  431(1++4)2 + 625.2.2    Multiple branching; double-plus expresses "from–to"
cr 431(1--3)1 →  431(2--4)1            Repetition of similar connections, expressed by
cr 431(1--4)1 . 54(1--4)1              the minus or double-minus sign

Page 230

(Figure 1). It is irrelevant whether a black box corresponds in the simplest case to a logic element — for example, a NAND gate — or whether it reflects, for example, the behavior of a complete computer in a computer network. What is important, by contrast, is that a black box actually stands in for a delimited portion of reality. The practical consequence can be illustrated by a simple example:

Consider the hardware prototype of a central processing unit with the typical assemblies “arithmetic unit,” “control unit,” and “memory.” Each assembly is sufficiently self-contained that it can be clearly delimited from the other assemblies and also tested independently. In order to test the interplay of the assemblies, appropriate connections must be established that lie between the assemblies and do not belong to the assemblies themselves. This mode of thinking and investigation, familiar from hardware construction, should be carried over into simulation technology as well. An assembly — that is, a black box — is to be represented as self-contained and independent of other black boxes. This implies, for example, that state variables must not be set in one black box and queried in another. The correspondence between black boxes takes place, exactly as in hardware construction, solely through intermediate connections.

For the simulation program package, this gave rise to a natural two-part division of the model description language.

a) The language BOMOL (Box Modeling Language) serves to describe black boxes. Given the diversity of conceivable black-box types with varying complexity and depth of modelling, a language that is as flexible as possible is required. BOMOL therefore fully encompasses the language ALGOL and additionally provides primarily for parallel programming. Naturally, when formulating black boxes, the user need only address questions that actually originate from the object. All simulation-specific problems — such as generating model time, monitoring and serializing concurrent processes, and performing stability checks — are handled by the auxiliary programs mentioned in the next section.

b) The language COMOL (Connection Modeling Language) is, by contrast, very simple. In principle, it suffices to simply list the connections by naming the black-box output and the

Page 231

corresponding black-box input in pairs. Already in Figure 1 it can be seen that repetition of similar connections or branching often leads to shorter notations. The various forms of connections are interconvertible by formula transformation. Since conventional problem-oriented languages offer little assistance for formula handling, the language COMOL was conceived as a new but very simple rule set.

3. The Structure of the Program Package

The simulation program package SAMO can be thought of — figuratively speaking — as a rack with initially empty compartments. The clear separation between the user section and the manufacturer section is essential. The manufacturer section contains the provided auxiliary tools, while the compartments of the user section are designated for the individual black-box types and interconnection networks. Four task types are possible — BOX, NET, TIE, RUN — which the user can trigger individually or in combination via a special compartment:

The BOX task: This task is aimed at handling an individual black-box type by itself — for example, introducing, correcting, or deleting it. In doing so, the BOMOL-to-ALGOL translator performs a syntax check and then generates an ALGOL representation of the relevant black-box type. Compartments 1 through 99 are reserved as a library for frequently used black-box types.

The NET task: A connection network formulated in COMOL merely indicates how the connections between the black boxes will be arranged in the future. A COMOL description can therefore be prepared without regard to whether the black-box types named therein are already available as BOMOL programs. The execution of the NET task — introducing, correcting, or deleting a connection network, syntax checking, and translation into an ALGOL representation — closely resembles the BOX task outwardly.

The TIE task: Through this task, the ALGOL representations of several black-box types and a connection network are assembled into an overall model description. Only through this “static ALGOL model description” does a consistency check become possible; for example, only at this point can it be

Page 232

[page 232: figure only]

Fig. 2 — Cooperation between user and manufacturer in the “operate and investigate model” phase

The figure shows the SAMO package rack structure with labeled compartments, translators, and control programs:

Manufacturer section (Herstellerteil):

Compartments for library black-box types in BOMOL representation (including library display devices)
BOMOL → ALGOL translator

User section (Anwenderteil):

Compartments for black-box types in BOMOL representation
Compartments for black-box types in ALGOL representation
COMOL → ALGOL translator
Compartments for connection networks in COMOL representation
Compartments for connection networks in ALGOL representation
Compartment for task description
Compartment for the static ALGOL model description

Control and simulation:

Coupling program (Kopplungsprogramm) — TIE
Master control program (Übergeordnetes Steuerprogramm)
RUN Simulator

Legend:

Solid arrows: control signals
Dashed arrows: transport of programs or data
Arrow A: The control program fetches the task description
Arrow B: The control program activates tasks BOX, NET, TIE, and/or RUN
Arrows C and D: The BOMOL → ALGOL translator fetches black-box types in BOMOL representation and returns them in ALGOL representation
Arrows E and F: The COMOL → ALGOL translator fetches a connection network in COMOL representation and returns it in ALGOL representation
Arrows G, H, I: The coupling program fetches the ALGOL representations of the black-box types and a connection network and forms from them a static ALGOL model description
Arrow K: Under the control of the simulator, the model is run dynamically

Page 233

determined whether a black-box input named in a connection was inadvertently omitted from the BOMOL representation of the relevant black-box type.

The RUN task: Only with this task does the actual simulation run begin. The possible processes specified in the static ALGOL model description are then actually played through dynamically. This requires an additional auxiliary program — namely the simulator. It must generate model time and correctly reflect within it the time-dependent processes running in the object. It must therefore keep track of all processes running simultaneously in the black boxes and, at the appropriate model time, initiate the exchange of information via the connections. This simulator operates in a “look-ahead” fashion and skips event-free intervals in model time. For program run time, therefore, it is not the step size of model time but the number of occurring events that is decisive. The simulator takes no notice of what the black boxes and connections it controls actually mean in content terms. It can thus be incorporated into the overall framework as an autonomous module and fulfills its function independently of the application domain.

The modular structure of SAMO permits largely independent improvement of the individual modules. The auxiliary tools provided in the manufacturer section currently comprise approximately 7,000 ALGOL lines.

4. Experience with SAMO from the Perspective of User-Friendliness

4.1 Effort Required to Learn SAMO

The rules of COMOL for describing connections can be learned in half an hour. Anyone who knows the language ALGOL 60 can become familiar with BOMOL in approximately one day. It has been found that even for more complex black-box types, the expressive means characteristic of ALGOL — such as dynamic array bounds, the block structure, or the special procedure-declaration technique — are hardly needed. One could therefore base BOMOL just as well on FORTRAN, COBOL, or even BASIC instead of ALGOL.

It is noteworthy that users of BOMOL frequently suspect pitfalls in the formulation of time dependencies and are reluctant to rely on the time-control mechanism provided by the auxiliary programs without having understood it themselves in detail.

Overall, the difficulties in learning the languages BOMOL and COMOL appear negligibly small compared to the problems encountered in model formation (see section 4.6).

4.2 Experience with the Presentation of Results

The wishes of users regarding the form of result display are, in practice, quite varied and differ above all between the testing phase and the operational phase of the simulation.

a) In the testing phase of the simulation, the model is to be brought into a logically correct form. In practice, a faulty model falls into a recognizably nonsensical overall state after only a few simulation steps (model time steps). It is therefore of great advantage for fault-finding if as complete a log as possible of all state changes has been recorded automatically. With increasing correctness, however, the volume of log data grows enormously. The automatic log must therefore be restrictable selectively — with respect to model location and model time — to the suspected source of error via special control data.

b) In the operational phase, the sought results are obtained. The investigation technique familiar from hardware prototyping is emulated here: display instruments are connected as required to appropriately selected points in the experimental arrangement. The black-box library therefore contains the models of frequently used display devices, so that results can be output in the form of tables, pulse diagrams, bar charts, or statistical figures (mean value, variance) as desired (see Figures 3 and 4). The user can also formulate custom display boxes using BOMOL.

Both in the testing phase and in the operational phase of a simulation run, the overall state of the model should be “saved” at regular time intervals. This makes it possible to resume a simulation run that was aborted due to some error at the most recently saved overall state, so that the error-free time segment need not be repeated.

Page 234

(continuation of section 4.2 and remaining sections)

The time required to understand the time-control mechanism, described at the end of section 4.1, should not be underestimated. The users tend to want to oversee every detail of the simulation’s time management themselves, rather than delegating it to the auxiliary programs. This attitude, understandable as it is, leads to additional learning overhead.

(Note: Page 234 represents the continuation of the Lagemann article on SAMO user-friendliness. The text extracted ends mid-section at the bottom of this page; subsequent sections — including 4.3 through 4.6 on further aspects of user-friendliness in the SAMO package — continue on pages beyond this range.)

Modelling Language

The Application Model will not be discussed here for reasons of time; instead, attention will now turn to the Configuration Model.

3. The Configuration Model

The Configuration Model consists of sub-models for the individual modules — such as processor cores, devices, and adapters — and of a model of the interconnection network. The modelling of the various modules is carried out independently of one another. The following sketches the modelling procedure and the concept on which the sub-models are based, using the example of a processor core.

Three phases can be distinguished in the modelling process:

In the first phase, the specification of the sub-model is defined. It consists of a listing of all so-called elementary actions that the sub-model can execute. In the case of the processor core, this yields, for example, the list shown in Figure 3a.

Figure 3a. Examples of elementary actions of a processor core [figure only — handwritten list in original]

[page 224]

In the second phase, each elementary action is defined in greater detail. This involves, for example, questions of the encoding of information and the specification and description of parameters for the individual elementary actions.

In the third phase, the order in which these elementary actions are to be triggered is defined. This order is of course not rigid, but depends essentially on three influencing variables, namely:

the elementary action currently being executed,
the information entering the sub-model from outside,
the AMOL statement of the Application Model currently being processed.

The result of this phase can be represented very clearly by a state diagram, as indicated in Figure 3b.

Figure 3b. Representation of the sequence of elementary actions by a state diagram [figure only in original]

[page 225]

The states represented as circles are assigned to the elementary actions (EA1 through EA7). It can be seen that, from the perspective of each elementary action, there are several possibilities for the order in which this graph can be traversed. The sub-model is thus controlled by the Application Model, by the environment, and by the internal state. From the perspective of automata theory, it therefore represents an extension of the Moore automaton.

Figure 4 shows the structural concept of the sub-model for a processor core. Its essential components are:

a memory into which the relevant portion of the Application Model is loaded,
a list of the elementary actions with all the specifications established in Phase 2 of the modelling process,
an action controller that is responsible for executing the respective elementary action,
an action program in which the sequence of elementary actions, as defined in the state diagram, is stored.

Particular emphasis is placed in this modelling concept — as sketched in this example — on modularity and flexibility: all essential parts of the model can be easily modified.

[page 226]

Figure 4. Concept for the structure of the processor core sub-model [figure only — block diagram with handwritten labels in original]

4. Status of Work

The initial preliminary investigations — in which smaller configurations (one processor core and a few devices each) were modelled and simulated — have been completed. At present, the model for the data acquisition system outlined at the beginning is being developed.

[page 227]

5. Concluding Remarks

If the problems and difficulties arising in the modelling process are to be identified, three categories can be cited:

Definition of the interface between the Configuration Model and the Application Model, i.e., the specification of the Application Modelling Language (AMOL), in order to obtain firm boundary conditions for the development of Configuration Models.
The collection and organization of all information about the object to be simulated that is essential for the modelling process.
The abstraction process leading from the object to the model, which includes, among other things, a substantial reduction of information.

30.4.1973 / RI / br

User-Friendliness in Simulation Technology

By Klaus Lagemann

Communication from the Philips Research Laboratory Hamburg

1. Introduction

The system considerations that become increasingly complex with each new computer family prompted the development management to address the use of simulation technology in the design of new computers for mid-range data processing. The development management proceeded from the practically oriented assumption that individual developers would naturally be occupied primarily with the problems of the design object — namely the new computer — and that simulation technology would serve merely as an investigative tool, the operation of which would in principle be learned in passing, just as one becomes accustomed to the use of the oscilloscope as an investigative tool. In practice, however, simulation technology proves to be a specialist craft; from the perspective of the development laboratory, it even appears to be a specialist science remote from practical application.

For the research laboratory, this raised the question of how simulation technology as a development tool could be made more user-friendly. This led to the creation of the simulation program package SAMO, which was initially installed on the Electrologica X8 computer and later also on the Control Data CD 6600. The following sections show how the SAMO package is shaped by the primary requirement of user-friendliness and what experience has been gained with it to date.

2. Structure and Description of a Model in SAMO

The program package SAMO was already reported on at the NTG specialist conference “Operating Systems” in Darmstadt on 12.4.72, so a summary will suffice here: The intended field of application — namely the simulation of computers — suggests representing the model of the object to be simulated as a system of black boxes and mutual connections (Figure 1). It is irrelevant whether a black box corresponds, in the simplest case, to a logic element such as a NAND gate, or whether it reflects, for example, the behavior of a complete computer in a computer network. What is important, however, is that a black box genuinely stands as a representative for a delimited portion of reality. The practical consequence can be illustrated with a simple example:

[page 229]

Figure 1. Model formation for the system structure of an object [figure — block diagram with COMOL connection syntax examples]

a) The model plan

The plan contains 4 black-box types (type numbers: 431, 522, 625, 54). Instances of the same type are numbered consecutively.

b) The model description of connections in COMOL

Syntax for the basic form of a connection: cr <Black-Box-type-no.> . <instance-no.> . <output-no.> . <Black-Box-type-no.> . <instance-no.> . <input-no.>

The complete connection network contains, in addition to the basic form, also compound forms. The factoring rules used are self-evident when compared with the model plan:

cr 431.1.2 → 522.1.2                          basic form
cr 431.2.2 → 522.1.1 + 625.1.2               branching, expressed by the plus sign
cr 431.3.2 → 625(1.2)1                        branching, with factoring of common numbers
cr 522.1.1 → 431(1++4)2 + 625.2.2            multiple branching; double-plus expresses "from–to"
cr 431(1--3)1 → 431(2--4)1                   repetition of similar connections, expressed by the minus or double-minus sign
cr 431(1--4)1 . 54(1--4)1

[page 230]

Consider a hardware test setup for a central unit with the typical assemblies “arithmetic unit,” “control unit,” and “memory.” Each assembly is self-contained to the extent that it can be clearly distinguished from the other assemblies and tested independently. To check the interaction of the assemblies, suitable connections must be established that lie between the assemblies and do not themselves belong to them. This way of thinking and investigating, familiar from hardware construction, should also be adopted in simulation technology. An assembly — a black box — is to be represented as self-contained and independent of other black boxes. It follows, for example, that state variables must not be set in one black box and read in another. The correspondence between black boxes is achieved, just as in hardware construction, exclusively via intermediate connections.

For the simulation program package, this led naturally to a two-part structure of the model description language:

a) The language BOMOL (Box Modeling Language) is used to describe black boxes. Given the diversity of conceivable black-box types with varying complexity and depth of modelling, as flexible a language as possible is needed. BOMOL therefore fully encompasses the language ALGOL and in essence additionally provides for parallel programming. Of course, the user needs to consider only the questions that actually arise from the object when formulating black boxes. All simulation-specific problems — such as the generation of model time, the monitoring and serialization of concurrent processes, and stability checks — are handled by the auxiliary programs mentioned in the next section.

b) The language COMOL (Connection Modeling Language), by contrast, is very simple. In principle it is sufficient to simply list the connections by naming, in pairs, the black-box output and the corresponding black-box input. Already from Figure 1 it can be seen that shorter notations often result from the repetition of similar connections or from branching. The various forms of connections are interchangeable by algebraic transformation. Since common problem-oriented languages offer little support for formula handling, the language COMOL was conceived as a new — though very simple — set of rules.

[page 231]

3. The Structure of the Program Package

The simulation program package SAMO can be thought of — figuratively speaking — as a rack with initially empty compartments. What is essential is the clear separation between the user section and the vendor section. The vendor section holds the provided auxiliary tools, while the compartments of the user section are reserved for the individual black-box types and connection networks. Four job types are possible — BOX, NET, TIE, RUN — which the user can invoke individually or in combination via a special compartment:

The BOX job: This job is aimed at handling a single black-box type in isolation — for example, loading it fresh, correcting it, or deleting it. In the process, the BOMOL–ALGOL compiler performs a syntax check and then generates an ALGOL representation of the relevant black-box type. Compartments 1 through 99 are reserved as a library for frequently used black-box types.

The NET job: A connection network formulated in COMOL merely specifies how the connections between black boxes will be laid out in the future. A COMOL description can therefore be prepared without regard to whether the black-box types named in it are already available as BOMOL programs. The procedure for the NET job — loading, correcting, or deleting a connection network, syntax checking, and translation into an ALGOL representation — outwardly resembles the BOX job closely.

The TIE job: Through this job, the ALGOL representations of several black-box types and a connection network are combined into a complete model description. Only through this “static ALGOL model description” does a consistency check become possible; for example, it is only at this point that one can determine whether a black-box input named in a connection was inadvertently omitted from the BOMOL representation of the relevant black-box type.

[page 232]

Figure 2. Collaboration between user and vendor in the “operate and investigate model” phase [figure — detailed block diagram of SAMO program package structure, with compartments for library black-box types, BOMOL and COMOL representations, translators, coupling program, and simulator; arrows labeled A through K indicating control flows and data transport]

Legend:

Solid arrows: control signals
Dashed arrows: transport of programs or data
Arrow A: The control program retrieves the job description
Arrow B: The control program activates jobs BOX, NET, TIE, and/or RUN
Arrows C and D: The BOMOL→ALGOL compiler retrieves the black-box types in BOMOL representation and returns them in ALGOL representation
Arrows E and F: The COMOL→ALGOL compiler retrieves a connection network in COMOL representation and returns it in ALGOL representation
Arrows G, H, I: The coupling program retrieves the ALGOL representations of the black-box types and a connection network and combines them into a static ALGOL model description
Arrow K: Under control of the simulator, the model is run dynamically

[page 233]

The RUN job: Only with this job does the actual simulation run begin. The possible processes named in the static ALGOL model description are actually played out dynamically. This requires a further auxiliary program — the simulator. It must generate model time and correctly reflect within it the temporal processes occurring in the object. It must therefore keep track of all processes running concurrently in the black boxes and, at the appropriate model time, initiate the exchange of information via the connections. This simulator operates “with look-ahead” and skips event-free intervals in model time. Consequently, program runtime is determined not by the step size of model time but by the number of events that occur. The simulator does not take note of what the black boxes and connections it controls actually mean in terms of content. It could therefore be incorporated as an autonomous module within the overall framework and fulfills its task independently of the application domain.

The modular structure of SAMO permits a largely independent improvement of the individual modules. The auxiliary tools provided in the vendor section currently comprise approximately 7,000 ALGOL lines.

4. Experience with SAMO from the Perspective of User-Friendliness

4.1 Observations on Learning BOMOL and COMOL

The rules of COMOL for describing connections can be learned in half an hour. Anyone familiar with ALGOL 60 can become acquainted with BOMOL in approximately one day. It has been found that even for more complex black-box types, the expressive means characteristic of ALGOL — such as dynamic array bounds, block structure, or the special procedure declaration technique — are scarcely needed. BOMOL could therefore be based equally well on FORTRAN, COBOL, or even BASIC instead of ALGOL.

It is noteworthy that users of BOMOL frequently suspect traps when formulating time dependencies and are reluctant to rely on the time-control mechanism provided by the auxiliary programs without having fully understood it themselves.

[page 234]

Overall, the difficulties in learning the languages BOMOL and COMOL appear negligibly small compared to the problems of model formation (see Section 4.6).

4.2 Experience with the Type of Results Display

Users’ wishes regarding the form of results display are, as experience shows, quite varied and differ above all between the test phase and the operational phase of the simulation.

a) In the test phase of the simulation, the model is to be made logically sound. Experience shows that a faulty model quickly reaches a recognizably absurd overall state after only a few simulation steps (model time steps). It is then of great advantage for fault-finding if as complete a log as possible of all state changes has been automatically recorded. With increasing freedom from errors, however, the volume of log data increases enormously. The automatic log must therefore be selectively limited, via special control data, by model location and model time, to focus on the suspected error source.

b) In the operational phase, the sought results are obtained. Here, the investigative technique familiar from hardware test setups is emulated, according to which display instruments are connected as needed to appropriately selected points of the experimental arrangement. The black-box library therefore contains the models of frequently used display instruments, so that results can be output as desired in the form of tables, pulse diagrams, bar charts, or statistical data (mean value, standard deviation) (see Figures 3 and 4). The user can also formulate custom display boxes with BOMOL.

Both in the test phase and in the operational phase of a simulation run, the overall state of the model should be “saved” at regular time intervals. This makes it possible to resume a simulation run that was interrupted due to some error at the most recently saved overall state, so that the error-free time span need not be simulated again.

[page 235: figure only]

Figure 3 (partial): Pulse diagram example — signal waveform printout [figure only — ASCII art pulse diagram from SAMO output]

[page 236]

Figure 4. Pulse diagram with varying amplitude (excerpt) [figure only — ASCII art pulse diagram from SAMO output, showing signal levels across time steps]

Figure 5. Measurement of idle times on a computer bus. Results display as bar chart, with mean value, standard deviation, minimum, and maximum.

ATMOD   17276
NUMBER OF MEASUREMENTS   330
MINIMUM      1
MAXIMUM   1019
MEAN VALUE            1.770606060608E+002
STANDARD DEVIATION    8.600548663957E+002

MEAS. VALUE  |
+  1  |************************************...  COUNT: 220
+  8  |*********                               COUNT:  10
+ 11  |**                                      COUNT:  16
+ 14  |*********                               COUNT:   3
+ 16  |****                                    COUNT:  16
+ 19  |*******                                 COUNT:   8
+ 22  |**                                      COUNT:  13
+ 24  |                                        COUNT:   6
+ 27  |******                                  COUNT:   1
+ 30  |**                                      COUNT:   9
+ 32  |*                                       COUNT:   3
+ 35  |***                                     COUNT:   2
+ 40  |**                                      COUNT:   6
+ 43  |                                        COUNT:   3
+ 46  |                                        COUNT:   1
+ 54  |***                                     COUNT:   5
+ 75  |**                                      COUNT:   1
+203  |*                                       COUNT:   3
+355  |*                                       COUNT:   1
+547  |*                                       COUNT:   1
+555  |*                                       COUNT:   1

[page 237]

Furthermore, a longer simulation run can be divided into shorter partial runs, which often allows better adaptation to the priority scheduling of the computing host. The “saving” of overall states, however, requires considerable effort in terms of auxiliary programs and storage space.

4.3 Experience with the Auxiliary Programs

The endeavor to spare the user as many inconveniences as possible when describing the model quickly leads to extensive auxiliary programs. This entails two risks:

a) In the event of machine errors on the computing system, the program package halts at some stage that is incomprehensible to the user. It is particularly difficult with the X8 to give the user a clear picture of the status of job processing even when an error abort occurs.

b) Contrary to original expectations, by far the majority of simulation jobs are of type “BOX” and “NET” and thus serve the construction of the model. From the user’s perspective, these are mostly small jobs for which a quick turnaround is expected. From the perspective of the computing host, however — due to the many auxiliary programs — a larger job is always generated, so that priority-induced waiting times can easily arise.

4.4 Experience with Runtimes

Almost every user initially encounters difficulties with the runtimes of the simulation programs. This did not change even after an increase in computing speed by a factor of 100. Evidently the user proceeds from a maximum runtime that seems reasonable to him — for example, 30 minutes — and removes superfluous details from his model until, within that runtime, he obtains just enough results. Thus the runtime question proves to be less of a problem of the simulator and more of a problem of suitable model formation.

[page 238]

4.5 Experience with the Transfer from the X8 to the CD 6600

The program package SAMO, completed for the X8, was to be transferred as quickly as possible to the CD 6600 in Frankfurt, so that it could be used via terminals both from Hamburg and from Eiserfeld. To achieve an optimal adaptation to the CD 6600, a thorough knowledge of that system would have been required. Such knowledge, however, cannot be acquired merely by consulting those responsible for the computer center or by studying manuals; rather, it requires hands-on experience with the installation of program packages, which in the present case was not available. The decision was therefore made to ‘simply’ transfer the entire package to the CDC system using special code-conversion programs — in, so to speak, a 1:1 ratio. The X8 input/output instructions were declared as CD 6600 ALGOL procedures whose body is composed of the corresponding CDC input/output instructions. Two special problems had to be solved:

a) The BOMOL-to-ALGOL and COMOL-to-ALGOL compilers process text only in X8 code. For the package installed on the CDC system, additional code-conversion programs were therefore needed, which are activated for every simulation job.

b) The disk storage organizations of the two systems are very different. The adaptation initially succeeded only by keeping a large reserve of data continuously shifted into working memory during simulation runs. The correspondingly large core memory requirement had extremely unfavorable consequences for the job’s placement in the computer’s queue and thus for waiting times.

Ultimately, therefore, the X8 has been emulated on the CDC system — and rather provisionally at that. This circumstance also has a very negative effect on the computing times for the preparatory simulation jobs “BOX” and “NET.” For the operational runs under the “RUN” job, however, the high computing speed of the CD 6600 can already be put to quite good use.

After a half-year conversion period and with now sufficient knowledge of the CDC system, the package is currently being optimized step by step. In the process, some auxiliary programs are also being rewritten in FORTRAN.

[page 239]

4.6 Problems in Model Formation

Even a user-friendly simulation program package does not solve the main problem of simulation technology: model formation. Suitable model formation can, for example, reduce simulation runtimes by a factor of 100 without any coarsening or distortion of the results. The topic of model formation has become an independent research program for the group. Among the goals of this program is the discovery of generally valid model structures and their automatic translation into the user’s conceptual framework at the display terminal. Furthermore, methods for modelling software are needed. In addition, the aim is to systematize — and thereby make more readily accessible to development practice — the knowledge about suitable modelling depth, confidence level, correct boundary conditions, and appropriate experimental design, beyond the stage of an experiential science.

References:

/1/ K. Lagemann: A modularly structured program package for the simulation of computer systems. Nachrichtentechnische Fachberichte, Vol. 44 (1972): Computer and Operating Systems; Analysis, Simulation, and Design.

/2/ K. Lagemann: Optimization of subscriber systems with intelligent and non-intelligent data terminals: Part 2, Model formation and simulation for system design. Research proposal to the Federal Ministry of Science, dated 14.2.72, Philips Research Laboratory Hamburg.

Simulation in Message Traffic Theory: Problem Formulations and Programming Languages

By G. Kampe, P. Kühn, and M. Langenbach-Belz

Institute for Message Switching and Data Processing, University of Stuttgart

1. Introduction

Message traffic theory investigates problems arising in switching systems for telephone or data traffic and in computer systems in the handling of message traffic flow. In addition to the analysis of existing systems, the synthesis of new systems (optimization) is also performed. A system is characterized essentially by its structure, its mode of operation, and the statistical properties of the message traffic. The usual methods of investigation are traffic measurements, exact or approximate calculations, and simulations on digital computers. Since the systems under consideration are often very complex, exact calculations cannot be carried out in many cases even with large computers. Simulation in message traffic theory therefore forms an indispensable tool wherever either no computational method is yet known or where the domain of validity of approximate computation procedures is being investigated.

Computational analysis — or analysis by simulation — is preceded by model formation. The actual resources and processes of reality are described by a model that is as faithful to reality as possible. The second section of the paper first presents the most important characteristics (structural elements, operating strategies, processes) of models in message traffic theory (briefly: traffic-theoretic models), and shows, using three typical examples from switching systems, computer systems, and networks, how a model is derived from the actual system. Brief attention is also given to the questions that the simulation is intended to answer.

The third section of the paper briefly presents the principal procedures for simulating such models using an example. Building on the findings of the preceding two sections, the fourth section addresses the requirements for languages for simulation programs in message traffic theory. Using a simple simulation model (single-stage waiting-and-loss system), the fifth section finally presents a comparison of the following four programming languages:

FORTRAN IV
GPSS/360
SIMSCRIPT 1.5
SIMULA 67

The system under consideration was modelled by a simulation program in each of these four languages. The experience gained with these languages (e.g., programming effort, memory requirements, program runtime) is discussed.

2. Problem Formulations in Communication Traffic Theory

2.1 General

In message switching systems, subscribers submit connection requests (demands), whereby these subscribers are to be automatically connected to a destination subscriber based on the dialed digits. The external stimuli trigger a series of processes within the switching system, such as connecting the subscriber to a free trunk circuit, attaching to a centralized register, recording and processing dialed digits, setting up the switching networks between the calling and called subscriber, etc. Due to the large number of connection requests and their statistically varying arrival times and holding durations, bottlenecks can arise within the switching system, manifesting as waiting times (delays in connection setup) or busy signals. In order to guarantee a sufficiently good service, it is necessary to dimension the central “service facilities” (trunks, registers, markers, processors, switching networks, etc.) adequately. Beyond questions concerning the required number of units, questions arise primarily regarding the optimal structure and optimal operating strategy by which service facilities are allocated to demands.

Within computer systems, very similar problems arise. Individual application programs place highly varied demands on the resources of the computer system (central processor, input/output units, backing stores, etc.). Larger computers are today largely organized according to the multiprogramming mode of operation. The simultaneous competition of several application programs for resources can likewise lead to internal bottlenecks, which can be avoided by appropriate dimensioning of these resources or by intelligent allocation through the operating system.

Long-distance telecommunications for telephone calls, telegrams, and data is handled over extensive networks. These networks consist of nodes with switching and control facilities, which are interconnected by communication channels. The structure of these networks and the operating strategy have a decisive influence on the handling of the communications traffic, particularly with regard to momentary bottlenecks that can arise through traffic peaks or partial failures.

2.2 Elements of Traffic-Theoretic Models

The most important elements for a complete description of a traffic-theoretic model are compiled in the following. They can be divided into three categories: structural elements, operating strategies, and processes.

2.2.1 Structural Elements

The structure of a model defines the possible “traffic paths” of demands through the system and also specifies the type, location, and number of its components (“structural elements”). The most important structural elements are summarized in Table 1 with a brief definition. During the flow of demands through the system, elements such as sources, service units, switching points, etc. can assume various discrete states (“free” or “occupied” or “blocked,” “open” or “closed,” etc.).

[page 242]

2.2.2 Operating Strategies

The operating strategies of a model describe the “traffic rules” by which demands flow through the system. Depending on the structural element, different types of strategies can be distinguished; see Table 2.

2.2.3 Processes

Communications traffic is generally characterized by statistical properties, such as the statistically varying time intervals between demands placed on a message switching system by a large number of subscribers, or the durations during which those subscribers occupy central facilities (trunks, registers, etc.). In the traffic-theoretic model, the statistically varying properties can be described by the “arrival process” and the “holding process,” each of which is defined by the probability distribution function (DF) of the inter-arrival times between demands and of the holding durations, respectively. Measurements in real systems have shown that most occurring processes can be described with sufficient accuracy by a small number of standard distribution functions.

For arrival processes, a distinction is made as to whether demands are generated by a finite number q or an infinitely large number of sources (q → ∞). Correspondingly, the DF A(t) of the inter-arrival times T_A is defined either per free source or for the totality of the sources:

(1)

A further important case arises when the arrival process is generated by an infinitely large number of sources but is “truncated” upon reaching a certain system state.

Correspondingly, the holding durations T_H are described by their DF H(t):

(2)

The most common types of DF for processes in communication traffic theory are compiled in Table 3.

2.3 Examples of Traffic-Theoretic Models

Model formation is demonstrated using three characteristic examples from switching systems, computer systems, and a network node. In each example, brief mention is also made of the questions to be answered through the analysis.

2.3.1 Multi-Stage Switching Networks in Message Switching Systems

When connecting calls between subscribers, or between internal trunk circuits and centralized registers, multi-stage switching arrangements (link systems) are frequently used. In these, connections are switched conjugately through several switching matrices (switching multiples).

Figure 1 shows an example of a structural model of a 4-stage link system with switching matrices arranged in stage j, j = 1, 2, 3, 4. The switching matrices between stages are

[page 243]

Table 1. Structural Elements of Traffic-Theoretic Models

Symbol	Type	Definition
(q, λ sources)	Traffic sources	Generation of demands according to an “arrival process.” a) q < ∞ traffic sources, arrival rate λ per free source. b) q → ∞ traffic sources, total arrival rate λ.
(service unit diagrams)	Service units	Servicing of one demand at a time according to a “holding process.” a) n = 1 service unit, termination rate μ. b) n > 1 service units (bundle, group), termination rates μ_1, …, μ_j, …, μ_n.
(buffer symbol)	Waiting buffer	Storage of at most s demands (waiting queue).
(switch symbol)	Switching point / Switch	Switching element for demands.
(matrix symbol)	Switching matrix / Switching multiple	Element for switching between i inputs and k outputs. Each connection is made via a switching point between a specific input and output.
(merge symbol)	Merge a / b	Element for the conditional merging of traffic from a or b (operating strategy governs priority).
(branch symbol)	Branch a / b	Element for the conditional branching of traffic to a or b (operating strategy governs direction).
(mixing diagram)	Mixing	Diagram for the merging (concentration) of lines in the mixing ratio (g·k) : n > 1. Described by matrix MS[1:k, 1:g], where MS[x, y] = number of the line at output x of switching matrix y.
(inter-stage diagram)	Inter-stage link structure	Diagram for the connection between outputs of switching matrices of stage j with inputs of switching matrices of stage j+1 (“inter-stage lines” or “link lines”). Various types of interconnection schemes are possible: “ordered,” “cyclically permuted”; concentration (mixing) between stages is also possible.

connected via an inter-stage link structure (“wiring scheme”) that can be specified. Between stages 1 and 2 there is additionally a concentration (mixing). The switching points and inter-stage links that are involved in a switched connection remain occupied throughout the entire holding duration (conversation duration or register holding time). (See the solid occupancy shown in Figure 1.)

Figure 1. Multi-Stage Switching Network (Link System)

Stages: 1, 2, 3, 4

At the output of the link system, the traffic is branched into R directions with n_r subscriber lines (= service units), r = 1, 2, …, R. Demands are generated by g_1 groups of q traffic sources each (arrival rate λ per free source). A waiting buffer of capacity s is provided per group.

As operating strategies, various selection strategies for service units, waiting queues, and demands within waiting queues are applicable; see Section 2.2.2. The inter-arrival times are generally negatively exponentially distributed; the holding durations are either likewise negatively exponentially distributed (telephone calls) or Erlang-k distributed (recording and processing of dialed digits in the register).

[page 246]

The most important performance metrics of the system to be determined are: waiting and loss probabilities, mean queue lengths, means and DFs of waiting times, and the individual bundle occupancies.

2.3.2 Multiprogramming in Computer Systems

Effective utilization of processors (P) and I/O channels in computer systems is possible through simultaneous operation and competition among multiple programs or program segments (segments, pages) in main memory. Figure 2 shows a queueing model that represents the most important traffic-theoretic aspects of a computer system with multiprogramming and paging.

New demands (programs) are generated at rate Λ and wait in a backing store (WS1) until they are transported via the I/O channel into main memory (WS3) with an initial load of pages. The processor P handles a program until completion or until an interruption due to a “page fault,” after which — following a management time — it generates a request to the I/O channel, which may wait in WS2 until the completed program is swapped out or a new page is loaded.

(New / reload / complete — labels from Figure 2)

As operating strategy, the priority rules for the merging (WS1, WS2) and the branching conditions (after I/O channel) must first be specified (see Figure 2). As selection strategies within the waiting queues, priorities or the normal arrival order may be used. The inter-arrival times of new programs are, for example, negatively exponentially distributed with arrival rate Λ. A frequently encountered practical case, however, is the assumption of a “saturated” waiting queue WS1, for which the arrival process is irrelevant. The holding durations of the I/O channel are integer multiples of a page transfer time; the processor holding times for a complete program or a program segment are generally hyperexponentially distributed.

Figure 2. Multiprogramming computer model

The performance metrics of interest are: means and DFs of waiting and sojourn times, loads of the processor P, the I/O channel, and the individual waiting buffers, and the mean number of interruptions per program.

2.3.3 Network Node

Telecommunications networks for telephone and data traffic are structured as a hybrid of pure star and mesh networks. Through this arrangement, a desired destination is reachable by several paths, and the network remains functional in the event of momentary bottlenecks due to traffic peaks or partial failures. However, to achieve economical utilization of transmission lines, the direct routes are heavily loaded, while the secondary and tertiary routes carry the “overflow traffic” and may therefore be less heavily loaded.

Figure 3 shows a section of a network containing, among others, nodes i, j, and k. Traffic from node i to node j is first

[page 247]

offered to the cheaper direct route with n_1 lines (primary bundle). If the direct route is fully occupied, the traffic overflows to the more expensive overflow route with n_2 lines (secondary bundle) and is routed via node k to node j. If both routes are occupied, a slot in the waiting buffer (capacity s) is occupied. If the waiting buffer is also fully occupied, an arriving demand is rejected and lost. The operating strategies define the overflow from the direct route to the overflow route, the selection of free lines within a bundle, and the selection of waiting demands from the waiting buffer. The inter-arrival times are, for example, negatively exponentially distributed; the holding durations are constant (data traffic).

Figure 3. Network node with direct and overflow route

The performance metrics of interest are: loads on the direct and overflow routes, waiting and loss probabilities, and the mean and DF of waiting times.

3. Simulation Methods

3.1 Description of the Example Model

Using the elements from Section 2, real systems can be represented as models, as indicated by the examples in Section 2.3. The example from Section 2.3.3 is examined in more detail in the following in order to describe the application of simulation technique and to show experiences with the use of programming languages (Section 5). Figure 4 again shows the model together with a description referring to the structure, the operating strategies, and the processes.

The goal of the simulation is to represent this model on a digital computer through a simulation program such that the following measured quantities can be obtained as results:

Before the waiting buffer:
- Arrival rate of demands realized in the simulation
- Loss probability
In the waiting buffer:
- Waiting probability
- Load
- Mean waiting time
- Waiting time distribution
In the primary bundle and secondary bundle, respectively:
- Load
- State probabilities
- Variance of the number of simultaneously occupied lines

Figure 4. Model description for the simulation example

	Structure	Operating Strategies	Processes
Traffic sources q → ∞	Arrival rate Λ	Loss when all waiting slots are occupied	Inter-arrival times: negatively exponentially distributed
Waiting buffer with s slots		Selection of waiting demand by FIFO
Primary bundle n_1 lines, Secondary bundle n_2 lines		Sequential scanning with overflow from primary bundle to secondary bundle	Holding durations in primary and secondary bundle: constant T_H = 1/c

3.2 Choice of Simulation Method

The simulation method must correctly reproduce above all the d y n a m i c behavior of the model (the sequence of events). Figure 5 shows a flow diagram that reveals that there are two t i m e p o i n t s at which a s t a t e c h a n g e occurs:

A demand arrives and occupies a line in the primary bundle, or occupies a line in the secondary bundle, or occupies a waiting slot (or is “lost,” which does not change the state of the model).
A demand releases a line and a waiting demand moves up, or the line remains free.

Since the sequence of events in the model can be completely described by these state changes or e v e n t s (whereby the time span between individual state changes is determined by the arrival and holding processes), it suffices in the simulation to reproduce the events in the model only at these d i s c r e t e time points (in contrast to continuous simulation, e.g., on an analog computer). If the holding durations were also negatively exponentially distributed, it would suffice for the measurement of means to consider only the probabilities for the occurrence of a state change (Monte Carlo method, roulette method, /1/). In the model under consideration, however,

Figure 5. Flow diagram for describing the dynamic behavior

(Flow diagram description: Arrival of a demand → Is primary bundle free? → Yes: Demand occupies a line in the primary bundle for time T_H (state change). / No: Is secondary bundle free? → Yes: Demand occupies a line in the secondary bundle for time T_H (state change). / No: Is waiting buffer free? → Yes: Demand occupies a waiting slot (state change). / No: Demand counted as lost (no state change). → Demand releases line (state change) → Is a demand waiting? → Yes: Dispatch demand from waiting buffer and determine waiting time (state change). / No: Line remains free.)

[page 250]

Figure 6. Evaluation of a measured quantity

(Diagram description: A measured quantity M is recorded over simulated time. There is a “run-in” period (Vorlauf), followed by 4 sub-test intervals (Teiltests). The mean as the result of a sub-test is shown. Final result: M-bar = (1/4) Σ_{i=1}^{4} M_i.)

Figure 7. Flow diagram for the framework program

(Flow diagram: Define structure of simulation model → Generate first demand → Perform arrival and dispatch of a demand in the model according to the flow diagram in Figure 5 → Sub-test complete? → No: Generate next demand → back to processing step. Yes: Determine results of sub-test → All sub-tests complete? → No: Generate next demand → back to processing step. Yes: Determine final results (means, confidence intervals) → Display final results → End of simulation or run with new parameters.)

[page 251]

the t i m e - t r u e (event by event) simulation method /2/ must be applied because of the constant holding durations, especially since individual waiting times must also be measured for the calculation of the waiting time distribution.

3.3 Execution and Evaluation of the Simulation

Since the state changes in the model are brought about by the arrival and dispatch of demands, a steady state in the model will be established only after a certain time (RUN-IN), cf. Figure 6. A statement about the statistical certainty with which the final result M (mean) of a measured quantity is determined can be made by subdividing the simulation into SUB-TESTS. From the sub-test results, the confidence interval for the measured quantities can be calculated (cf. /3/ through /5/). The execution of RUN-IN, SUB-TESTS, and evaluation takes place in the so-called framework program (cf. /6/, /7/), which is shown as a flow diagram in Figure 7.

In the model under consideration, the number of sources is infinitely large. Therefore, the arrival rate of demands is equal to Λ at every instant, and the negatively exponentially distributed inter-arrival time T_A is mathematically very simply expressed as

T_A = −(1/Λ) ln(z)

with the random variable z, which is uniformly distributed between 0 and 1. Many examples in communication traffic theory, however, have a finite number of sources. The problems arising in simulation in this case are discussed in detail in /8/.

4. Fundamental Requirements for Simulation Languages in Communication Traffic Theory

In Sections 2 and 3, the problem formulations and the simulation method as typical for communication traffic theory were explained. From this, the following requirements for an “ideal” simulation language (IL) for carrying out a discrete, time-true simulation according to Section 3.2 are derived.

4.1 Model Description

The elements of the IL should correspond to the typical elements (Section 2.2) of models from communication traffic theory and should be conveniently linkable with one another (e.g., for inter-stage line arrangements). The user can freely define variable names. M a c r o c o m m a n d s should allow the representation of operating strategies as well as processes. The simulated time axis is to be managed by an independent time-control program (monitoring the sequence of events), with time quantities treated as floating-point numbers.

4.2 Logical and Arithmetic Operations, Statistics

The IL should permit integers, floating-point numbers, and Boolean expressions as variables. A function library should provide the frequently used functions (e.g., ln, square root). Procedures for the most common distribution functions should be available (cf. Section 2.2.3). The measurement data obtained in the simulation should be statistically evaluable without extensive programming effort (means, confidence intervals, histograms).

[page 252]

4.3 Input/Output

Input should be possible without a prescribed format. The initial values and the structure of the model should be easy to change. Convenient instructions should be available for formatting the printer output (often tables), and output commands for writing data to external storage (tape, disk) should also be present.

4.4 Testing Capabilities

Syntactic and logical errors, as well as an incorrect sequence in the flow of events, should be made visible through “snapshot” diagnostics (printing the values of all variables) or check routines. The compiler should have detailed error diagnostics, and the user manual should explain remedies for errors in a generally understandable manner.

4.5 Miscellaneous

The IL should be easy to learn, economical with computation time and memory space, and allow a clear program structure that simultaneously permits a model-appropriate formulation of the simulation problem.

5. Experiences with 4 Programming Languages

The following section shows the experiences gained in developing a time-true simulation program using the programming languages FORTRAN IV, GPSS/360, SIMSCRIPT 1.5, and SIMULA 67. The simulation model used was the example in Figure 4. The simulation programs themselves (cf. /9/ through /12/) as well as the programming languages (cf. /13/ through /21/) will not each be explained in full detail. For a fundamental comparison of programming languages, reference is made to literature /22/ through /32/.

5.1 General Notes on FORTRAN, GPSS, SIMSCRIPT, SIMULA

Whereas FORTRAN (like ALGOL) is a universal, problem-oriented programming language, the simulation languages GPSS, SIMSCRIPT, and SIMULA belong to special problem-oriented programming languages and fulfill in some parts the requirements stated in Section 4. In particular, the three last-named programming languages have some language elements for describing typical model elements. Table 4 summarizes some important characteristics of the three simulation languages. These characteristics are explained in more detail when describing the application of the individual languages (Sections 5.3 through 5.5).

Since not only the capability but also the availability of a programming language determines its use, Table 5 lists some compiler manufacturers for GPSS, SIMSCRIPT, and SIMULA. A FORTRAN compiler is certainly available for nearly every digital computer. For the simulation example, compilers were used on an IBM 360/40 (GPSS/360) and a CDC 6600 (FORTRAN IV, SIMSCRIPT 1.5, SIMULA 67).

Table 4. Characteristics of GPSS, SIMSCRIPT, SIMULA

Characteristic	GPSS	SIMSCRIPT	SIMULA
Moving unit (e.g., a demand)	TRANSACTION	TEMPORARY ENTITY	PROCESS (instance of an ACTIVITY)
Service unit (e.g., a trunk bundle)	FACILITY (1 slot), STORAGE (> 1 slot)	PERMANENT ENTITY	PROCESS
Property of a unit (e.g., point in time at which a demand enters a waiting buffer)	PARAMETER	ATTRIBUTE	ATTRIBUTE
Group into which units can be ordered (e.g., waiting buffer)	CHAIN	SET	SET
Event type	Determined by the block the TRANSACTION passes through	Defined in the EVENT, a self-contained program section	Defined by the operational rules in the PROCESS, executed in its active phase
Time control	Blocked or active TRANSACTIONS are organized in internal CHAINS	EVENTS are entered in the internal calendar	SEQUENCING SET organizes the temporal sequence of the active phases of the PROCESSES

[page 254]

Table 5. Compilers for GPSS, SIMSCRIPT, SIMULA (after /32/)

GPSS	SIMSCRIPT	SIMULA
Version/Manufacturer/Series	Version/Manufacturer/Series	Manufacturer / Series
II — UNIVAC 1107, 1108	III — CONTROL DATA CORP. 3600	BURROUGHS B5500
III — IBM 7090, 7094, 7040, 7044	? — PHILCO-FORD 210, 211, 212	CONTROL DATA CORP. 6400, 6500, 6600
/360 — IBM 360/370	I — IBM 7090, 7094	IBM 360/370
	I.5 — CONTROL DATA CORP. 3600, 3800, 6400, 6500, 6600	UNIVAC 1107, 1108
	I.5 — GENERAL ELECTRIC 625, 635
	I.5 — IBM 360/
	I.5 — RCA Spectra 70, Info-Systems Mod. 45
	I.5 — UNIVAC 490, 1107, 1108
	II — IBM 360/

5.2 Application of FORTRAN IV to the Simulation Example

Since FORTRAN has no language elements for describing typical model elements (waiting buffer, service units, etc.), the model must be represented using indexed variables that record, for example, the occupancy state and occupancy statistics. The negatively exponentially distributed inter-arrival times are represented by uniformly distributed pseudo-random numbers (cf. Section 3.3), which in FORTRAN can be called via a library function. The time sequence is controlled via an array into which the next pending event is entered each time. The typical operations in the course of the simulation (searching for a free line, occupying a waiting slot, evaluating a sub-test) can be represented by SUBROUTINES and FUNCTIONS, giving the program a certain degree of clarity.

Essentially, the flow diagram of the FORTRAN program corresponds to the flow diagrams shown in Figures 5 and 7. A disadvantage for the readability of the program, however, is that the description of the operations in the simulation requires multiple statements for each step.

Input in FORTRAN IV is format-bound; the design of the output (e.g., tables) is somewhat cumbersome for simulation purposes. Logical and syntactic errors are analyzed in detail. The temporal flow can be monitored by print statements. FORTRAN IV is well documented and easy to learn. Program execution time and memory requirements: see Section 5.6.

[page 255]

5.3 Application of GPSS/360 to the Simulation Example

5.3.1 Model Description in GPSS/360

The simulation language GPSS/360 represents the model and the events occurring within it by means of a flow diagram whose blocks are each described by a macro command. Each block is defined in its effect by a series of parameters. This effect is exerted by the block on the moving parts of the model — the TRANSACTIONS — as soon as they pass through it or reside in it (e.g., a demand occupies a line). Each TRANSACTION can be located at only o n e position in the flow diagram at any given time. TRANSACTIONS can be queued in waiting buffers and can leave them again under specifiable conditions. A TRANSACTION can be described by a maximum of 100 PARAMETERS.

The sequence of events in the model in GPSS/360 depends on the state of all TRANSACTIONS present in the model, whereby a particular TRANSACTION is always transported through the flow diagram until it either reaches an ADVANCE block (holding duration) or is blocked from further progress, for example, because a FACILITY block (service unit) it encounters is already occupied. The program control then seeks the next movable TRANSACTION in the model.

Some language elements used in the simulation example:

GENERATE block — generates demands (TRANSACTIONS) at time intervals corresponding to a specifiable FUNCTION (pairs of values describing the interpolation points).
STORAGE — multiple service units, 1 trunk bundle.
QUEUE — waiting buffer in which demands waiting before a STORAGE are accommodated.
TEST block — conditional query.
TERMINATE — deletes a demand after the completion of its traversal.

5.3.2 Logical and Arithmetic Operations, Statistics in GPSS/360

Difficulties arise for the simulation example regarding arithmetic operations in that variables in GPSS/360 represent a Boolean quantity or can only assume integer values. This means that all results relating to probabilities must be multiplied by, for example, a factor of 10^5 during the calculation. However, this must not cause the u p p e r numerical range limit of 2^31 − 1 to be exceeded (in intermediate calculations). A further disadvantage is that important library functions are missing: for the calculation of the confidence interval, the square root function is needed, which must be entered in GPSS/360 via interpolation points (polygon). Very advantageous is the automatic generation of statistical data for service units and waiting buffers. For example, the following 8 quantities are determined for a waiting buffer:

Load
Total number of TRANSACTIONS that have waited
Total number of TRANSACTIONS that did not have to wait
Probability of not having to wait
Mean waiting time of all TRANSACTIONS that passed through
Mean waiting time of all waiting TRANSACTIONS
Current number of waiting TRANSACTIONS
Maximum number of waiting TRANSACTIONS

[page 256]

5.3.3 Input/Output in GPSS/360

The essential input data for describing the simulation example are consolidated in the simulation program on successive cards in a separate program section (MACRO). For output to a printer, GPSS/360 provides two types of commands:

Selection, labeling, and commenting of statistics
Graphical output (diagrams)

5.3.4 Testing Capabilities in GPSS/360

The automatically generated statistics greatly facilitate testing. Most programming errors are additionally analyzed by the compiler and identified by a code number.

5.3.5 Miscellaneous for GPSS/360

The compact, clear structure of GPSS/360 contributes to the rapid learnability of the language. The transition from the flow diagram to the program can be made directly. Readability of the program suffers somewhat from the fact that the programmer is bound to the prescribed parameter names and cannot choose model-related parameter designations freely. Program execution time and memory requirements: see Section 5.6.

5.4 Application of SIMSCRIPT 1.5 to the Simulation Example

5.4.1 Model Description in SIMSCRIPT 1.5

The structure of this simulation language requires a clear separation of the model into a static part (defined by PERMANENT ENTITIES and their ATTRIBUTES) and a dynamic part, i.e., program sections that permit the execution of state changes (EVENTS). For the simulation example, two EVENTS are required according to Section 3.2:

Arrival of a demand with the query as to whether it can be dispatched immediately, or waits, or is lost.
Release of a line with the query as to whether a demand is waiting and to occupy this line anew.

For organizing the simulated time axis, an “internal calendar” is available in which the time point for an event’s occurrence is entered either at the start of the simulation (EXOGENOUS EVENT) or during the course of the simulation depending on certain conditions (ENDOGENOUS EVENT). The respective event occurs when the statements of the relevant program section are executed. As “moving” elements of the model, TEMPORARY ENTITIES are created, which are described by TEMPORARY ATTRIBUTES and can be arranged in groups (SETS) (FIFO, LIFO, or depending on the numerical value of a TEMPORARY ATTRIBUTE). The definition of all quantities (other than local variables) and a breakdown into TEMPORARY VARIABLES, PERMANENT VARIABLES, SETS, and FUNCTIONS is performed using a DEFINITION form, on which the memory requirements of each variable (full words, half words, third words) must also be specified.

Some language elements used in the simulation example:

CREATE ruf — creates a demand (TEMPORARY ENTITY) that can be addressed under the name “ruf.”

[page 257]

CAUSE ankft AT 2.0 — enters the event “arrival” (ankft) at time point 2.0 in the internal calendar.
FILE ruf IN wart — inserts the TEMPORARY ENTITY “ruf” into the waiting buffer “wart.”
DESTROY ruf — destroys the TEMPORARY ENTITY “ruf” and its TEMPORARY ATTRIBUTES. This frees the relevant memory locations for other, new TEMPORARY ENTITIES (dynamic memory management).

5.4.2 Logical and Arithmetic Operations, Statistics in SIMSCRIPT 1.5

The relationship between SIMSCRIPT and FORTRAN is evident in that the possibilities for arithmetic operations are the same in both languages, with the exception that SIMSCRIPT does not know Boolean variables. For generating statistical data, SIMSCRIPT has statements that allow running integration of measured values over time, as well as the calculation of, for example, means, variance, or standard deviation from a series of values. The functions available in the FORTRAN subroutine library are also available. Additionally, custom FUNCTIONS can be defined, or function curves can be entered via pairs of values (interpolation points).

5.4.3 Input/Output in SIMSCRIPT 1.5

The values of all PERMANENT VARIABLES at the start of the simulation, and thus also the initial state of the model, are specified in an INITIALIZATION form. The prescribed format requires increased effort when creating the input data. The design of the output on a printer is defined by REPORT statements, which permit a clear formulation of print commands.

However, the auxiliary programs generated by the compiler for this require a relatively large amount of memory space. Write commands for transporting data to external storage are available.

5.4.4 Testing Capabilities in SIMSCRIPT 1.5

Since the simulation program consists of self-contained sections (EVENTS, SUBROUTINES), no unified flow diagram for the entire temporal simulation sequence can be created. The correct temporal sequence can, however, be verified by print statements within an EVENT. The compiler prints detailed error messages during translation. Error diagnosis during the simulation run was, however, not always satisfactory in the present case.

5.4.5 Miscellaneous for SIMSCRIPT 1.5

For those familiar with FORTRAN, SIMSCRIPT is easy to learn. The free naming convention makes the program easily readable. In the newer version SIMSCRIPT II /15/, some disadvantages — above all regarding the strictly formal data input — have been corrected. Program execution time and memory requirements: see Section 5.6.

[page 258]

5.5 Application of SIMULA 67 to the Simulation Example

5.5.1 Model Description in SIMULA 67

The elements in the simulation model that undergo changes or trigger changes during the simulation are represented by PROCESSES, which are individually characterized by ATTRIBUTES and whose behavior is defined by a sequence of associated statements (operational rules). Among other things, the statements cause the PROCESS to be in an a c t i v e phase (corresponding to an occurring event, EVENT) or in a p a s s i v e phase. A scheduling mechanism (SEQUENCING SET) manages the temporal sequence of active phases among all PROCESSES present in the system, with always only 1 PROCESS being active at a time. PROCESSES with the same behavior (i.e., the same sequence of operational rules but different ATTRIBUTE values) are described by one and the same program section (ACTIVITY). The variable ELEMENT allows a reference to a PROCESS. ELEMENTs can be arranged in groups (SETs). The declaration of ACTIVITIES, ATTRIBUTES, etc. takes place (as in ALGOL) in a declaration section at the beginning of the nested blocks.

Some language elements used in the simulation example:

‘ACTIVATE’ ‘NEW’ ruf ‘AT’ 2.0 — initiates the call to the PROCESS “ruf” (via ‘NEW’ ruf) and its activation, i.e., the execution of its operational rules, at time 2.0.
CURRENT.INTO(wart) — the ELEMENT of the currently active PROCESS (representing a demand) is placed in the waiting buffer.

An individual PROCESS is terminated — i.e., memory is freed — as soon as the statement ‘END’ is reached in the execution of the operational rules describing it.

5.5.2 Logical and Arithmetic Operations, Statistics in SIMULA 67

The development of SIMULA from ALGOL 60 is recognizable, among other things, by the fact that both languages have the same logical and arithmetic operations and that the syntax of ALGOL 60 has been almost completely adopted into SIMULA. A large number of distribution functions can be called directly in SIMULA 67 via procedure names, which greatly facilitates the representation of processes. Procedures are available for generating statistical data, e.g., integrating values over time or calculating histograms.

5.5.3 Input/Output in SIMULA 67

Input is completely free-format: data to be read in need only be separated by at least one blank. A large number of statements is available for designing the output (convenient table output).

5.5.4 Testing Capabilities in SIMULA 67

Errors are analyzed in detail and printed both during translation and during the simulation run. The correct temporal sequence can be verified with print statements at decisive points in the program.

5.5.5 Miscellaneous Remarks on SIMULA 67

SIMULA is relatively easy to learn for those familiar with ALGOL, although understanding the fundamental concept of the language may initially present difficulties. It must of course be borne in mind that SIMULA 67, beyond its use as a simulation language, also supports convenient list processing in general, which makes the language as a whole rather extensive. The simulation programs produced are highly readable thanks to the free choice of variable names and the block structure of the language. For run time and memory requirements, see the next section.

5.6 Comparison Results

By way of summary, and with regard to suitability for simulation problems in telecommunications traffic theory, the following assessment of the three simulation languages GPSS, SIMSCRIPT, and SIMULA can be stated:

Structural elements and the sequence of processes within the model can be very conveniently represented in GPSS (direct translation of the flow diagram).
Operating strategies are particularly well suited to implementation in SIMSCRIPT.
Processes can only be modeled simply when the most common distribution functions are available. The lack of library functions in GPSS is particularly unfavorable, whereas SIMULA provides an exemplary range of distribution functions.
The generation of statistical data is performed automatically in GPSS (at the cost of increased computation time), but variables can only take integer values. SIMSCRIPT and SIMULA provide adequate tools for statistical data generation.
For the input of data and initial conditions, the free-format form in SIMULA is particularly helpful.
All three simulation languages, insofar as the compilers used in the simulation example permit such a judgment, offer adequate error diagnostics.
Output is made very simple and clear in SIMSCRIPT through report forms.
The learning effort increases from GPSS through SIMSCRIPT to SIMULA, though this also depends on the quality of the manual available in each case.

To determine run time and memory requirements, the programs written in FORTRAN IV, GPSS/360, SIMSCRIPT, and SIMULA were each supplied with the same input parameters and a simulation run was performed with each.

Figure 8. Comparison values for the simulation example

s = 5, n1 = 3, n2 = 2, Warm-up: 500 requests; 10 partial tests: 5,000 requests each.

Programming Language	Memory (words, 60-bit)	Compilation Time (sec)	CPU Time (sec)	I/O Time (sec)	Punch Cards
FORTRAN IV	14,000	2.0	9.7	13.1	450
GPSS/360	30,000	79.2	2,049.5	—	340
SIMSCRIPT	33,000	48.5	34.2	58.5	350
SIMULA	17,700	6.3	379.4	19.5	360

Figure 8 shows the results. The comparison with GPSS/360 is not entirely appropriate, as a different computer (IBM 360/40) was used for that program than for the other three. Apart from the choice of compiler, other factors also fundamentally influence the comparison results: the skill and experience of the programmer, the complexity of the model, the scope of the desired statistical analysis, and the requirements for output of results.

Taking into account all experience gathered so far — which must of course be limited in scope — the impression is gained that SIMSCRIPT and SIMULA can currently be regarded as suitable simulation languages for many problems in telecommunications traffic theory.

References

/1/ KOSTEN, L.: On the Measurement of Congestion Quantities by Means of Fictitious Traffic. HET PTT-Bedrijf (1948/49), 15–25.

/2/ NEOVIUS, G.: Artificial Traffic Trials Using Digital Computers. Ericsson Technics 11 (1955), 279–291.

/3/ LOTZE, A.: Uber die statistische Sicherheit von Verkehrsmessungen [On the statistical reliability of traffic measurements]. NTZ 11 (1958) 1, 5–7.

/4/ SCHMETTERER, L.: Einfuhrung in die mathematische Statistik [Introduction to Mathematical Statistics]. Springer-Verlag, Vienna, New York, 2nd ed. 1966.

/5/ KUMMERLE, K.: Ein Vorschlag zur Berechnung der Vertrauensintervalle bei Verkehrstests [A proposal for the calculation of confidence intervals in traffic tests]. A.E.U. 23 (1969) 10, 507–511.

/6/ HUBER, M., WAGNER, W.: Simulation von Nachrichtenvermittlungssystemen [Simulation of message switching systems]. In: Nicht-numerische Informationsverarbeitung, ed. R. Gunzenhauser, Springer-Verlag, Vienna, New York, 1968.

/7/ WAGNER, H., DIETRICH, G.: Bestimmung der Verkehrsleistung von Wartesystemen durch kunstlichen Fernsprechverkehr [Determination of the traffic performance of queueing systems by means of artificial telephone traffic]. NTZ 17 (1964) 6, 273–279.

/8/ WEISSCHUH, H.: Theoretical Aspects of Finite Source Input Process Simulation. 7th International Teletraffic Congress, Stockholm, 1973.

/9/ RAKOTOMANGA, D.: Simulationsprogramm in FORTRAN fur ein Warte-Verlustsystem mit Uberlauf [Simulation program in FORTRAN for a queueing-loss system with overflow]. Monograph, Institut fur Nachrichtenvermittlung und Datenverarbeitung, Universitat Stuttgart, 1970.

/10/ THIEL, K.-H.: Simulationssprache GPSS [GPSS simulation language]. Monograph, Institut fur Nachrichtenvermittlung und Datenverarbeitung, Universitat Stuttgart, 1970.

/11/ PFEIFFER, H.: Nachbildung der Datenubertragung zwischen zwei Vermittlungsrechnern mit Hilfe der Simulationssprache SIMSCRIPT, Teil 1 [Simulation of data transmission between two switching computers using the SIMSCRIPT simulation language, Part 1]. Monograph, Institut fur Nachrichtenvermittlung und Datenverarbeitung, Universitat Stuttgart, 1970.

/12/ DITZEL, D.: Simulationssprache SIMULA [SIMULA simulation language]. Monograph, Institut fur Nachrichtenvermittlung und Datenverarbeitung, Universitat Stuttgart, 1972.

/13/ IBM: General Purpose Simulation System/360 User’s Manual. IBM No. H20-0326-3, 1968.

/14/ MARKOWITZ, H.; HAUSNER, B., KARR, H.: SIMSCRIPT: A Simulation Programming Language. The Rand Corporation, Santa Monica, Calif., RM-3310, Nov. 1962.

/15/ KIVIAT, P.J., VILLANUEVA, R., MARKOWITZ, H.: The SIMSCRIPT II Programming Language. Prentice-Hall, Inc., New Jersey, 1968.

/16/ KAMPE, G.: SIMSCRIPT. Vieweg-Verlag, Braunschweig, 1971.

/17/ RAEHMEL, Ch.-A.: SIMSCRIPT — eine Simulationssprache [SIMSCRIPT — a simulation language]. Computerpraxis 5 (1972) 11, 321–327.

/18/ DAHL, O.J., NYGAARD, K.: SIMULA, a language for programming and description of discrete event systems. Introduction and User’s Manual. Norwegian Computing Center, Oslo, 1966.

/19/ CONTROL DATA CORPORATION: 6400/6500/6600 Computer Systems: SIMULA Reference Manual. No. 60234800 Rev. A, Palo Alto, 1969.

/20/ NIEDEREICHHOLZ, J.: Einfuhrung in die Simulationssprache SIMULA [Introduction to the SIMULA simulation language]. El. Datenverarbeitung 12 (1970) 5, 204–207.

/21/ BOESCH, R., BENN, J.: SIMULA 6000 — Beispiele [SIMULA 6000 — Examples]. Rechenzentrum der FIDES-Treuhandvereinigung, Publ. 36, 1st edition 1970.

/22/ TOCHER, K.D.: Review of Simulation Languages. Operations Research Quarterly, 16 (1965) 2, 189–217.

/23/ FENNEL, H.J.: Simulation und die Simulationssprachen SIMSCRIPT und GPSS II [Simulation and the simulation languages SIMSCRIPT and GPSS II]. El. Datenverarbeitung 7 (1965) 3, 130–140.

/24/ TEICHROEW, D., LUBIN, J.F.: Computer Simulation — Discussion of Technique and Comparison of Languages. Comm. ACM 9 (1966) 10, 723–741.

/25/ KRASNOW, H.S.: Dynamic Presentation in Discrete Interaction Simulation Languages. In: “Digital Simulation in Operations Research”, S.H. HOLLINGDALE (Ed.), The English Universities Press Ltd., London, 1967.

/26/ WEINERT, A.E.: A SIMSCRIPT-FORTRAN case study. Comm. ACM 10 (1967) 12, 781–792.

/27/ BUXTON, J.N. (Ed.): Simulation Programming Languages. North-Holland Publishing Company, Amsterdam, 1968.

/28/ KIVIAT, P.J.: Digital Computer Simulation: Computer Programming Languages. The Rand Corporation, Santa Monica, Calif., RM-5883-PR, Jan. 1969.

/29/ NOSKA, T.: Ermittlung der fur Planung und Betrieb von Huttenwerken geeigneten Simulationssprachen [Determination of simulation languages suitable for the planning and operation of steelworks]. Dissertation, Montanistische Hochschule Loeben, 1970.

/30/ BERGER, B., SEIBT, D., STRUNZ, H.: Bibliographie des Betriebswirtschaftlichen Institutes fur Organisation und Automation an der Universitat Koln zum Thema “Programmiersprachen” [Bibliography of the Institute for Business Administration, Organization and Automation at the University of Cologne on the topic of “Programming Languages”]. El. Datenverarbeitung 11 (1969) 5, 225–234; 7, 330–341; 8, 387–397.

/31/ LUTTGENS, H.-G., SEIBT, D.: Erganzungen zu Literatur /28/ [Additions to reference /28/]. Angewandte Information 13 (1971) 3, 137–144.

/32/ EMSHOFF, J.R., SISSON, H.L.: Simulation mit dem Computer [Simulation with the Computer]. Verlag Moderne Industrie, Munich, 1972.

Simulation of Message Sources in Block-Oriented Simulation Models

Burkhardt Hinsch — GMD II 7

Quantitative requirements are placed on a data communications network (DFV-Netz) that it must satisfy under certain boundary conditions. The question of whether and to what extent a conceived network will meet these requirements can hardly be answered by exact mathematical methods. Simulation constitutes a quasi-experimental technique for obtaining quantitative statements about a network prior to its realization.

In the area of simulation, the focus of work is on the development of simulation models of varying levels of detail. The goal is the development of pre-programmable modules for the individual components of a data communications network. The suitability of simulation languages for this purpose is also being investigated (GPSS V, SIMSCRIPT II, CSMP/360). The aim, on the one hand, is to shorten the generally very time-consuming phase of model construction, and on the other hand — to some extent as a consequence of this — to enable the data required for simulation to be compiled earlier and more specifically.

In this context, the problem of modeling message sources as one of the components of a data communications network has also been addressed. The conclusion reached is that the following 4 basic model types cover the essential cases that arise in practice:

An uncontrolled message source that generates only messages of a single message type.
An uncontrolled message source that generates messages of several message types according to a defined statistical distribution.
A controlled message source that generates logically interconnected sequences of messages.
Two mutually controlling message sources for the simulation of a dialog.

In the following, each of the individual models and its formulation in a block-oriented simulation language (GPSS) is described.

1. Simulation of Uncontrolled Message Sources That Generate Only Messages of a Single Message Type

Model:

The message source is to generate messages autonomously of a defined message type, with a length that is normally distributed around a defined mean value. The message is to be delayed in the processing unit by a time that is likewise normally distributed around a defined value. The time interval between individual messages is uniformly distributed around a mean value within an interval of defined length.

Program:

Each message is represented by a transaction with three parameters each:

Par. 1 contains the message type.
Par. 2 contains the message length.
Par. 3 contains the delay time.

Function FN1 serves as the modifier for message length and delay time; it approximates a normal distribution with mean mu = 1 and standard deviation sigma = 0.1.

Three message sources are modeled in the program, each generating messages of message type 1, 2, and 3 respectively, with a uniform mean length of 500 characters and a uniform mean delay time of 100 ms.

The time interval between individual messages is uniformly distributed within the interval 15,000 ms ± 5,000 ms for all three message sources.

As the processing unit, a simple concentrator with speed conversion is modeled.

The incoming messages are accepted into a shared memory and placed in a processing queue, from which they are processed on a FIFO basis. The processing time is taken from Par. 3 of the message. After processing, the message is sent directly from memory via the outgoing line. The processing unit and the outgoing line remain occupied for the duration of transmission; the memory occupied by the message is not released until transmission is complete.

2. Simulation of an Uncontrolled Message Source That Generates Messages of Several Message Types According to a Defined Statistical Distribution

Model:

The message source is to generate messages of three different message types autonomously, occurring with defined probabilities. Depending on the message type, each message is assigned a defined length and delay time, as under case 1. The time interval between individual messages is uniformly distributed around a mean value within an interval of defined length.

Program:

Each message is represented by a transaction with three parameters each:

Parameter 1 contains the message type.
Parameter 2 contains the message length.
Parameter 3 contains the delay time.

Function FN1 serves as the modifier for message length and delay time; it approximates a normal distribution with mean mu = 1 and standard deviation sigma = 0.1.

One message source is modeled in the program, generating messages of message types 1, 2, and 3 respectively, with mean lengths of 500, 400, and 300 characters and mean delay times of 100, 80, and 50 ms. The probability of occurrence of message types 1, 2, and 3 is 0.2, 0.5, and 0.3 respectively. The time interval is uniformly distributed within the interval 25,000 ± 5,000 ms.

3. Simulation of a Controlled Message Source That Generates Logically Interconnected Message Sequences

Model:

The message source is to generate logically linked message sequences, in which each message is assigned one of 4 possible message types A, B, C, and Z depending on the type of the preceding message. The message types form a Markov chain. The following matrix lists the transition probabilities from message types A, B, C, Z to message types A, B, C, Z, where the matrix element (X, Y) (X = A, B, C, Z; Y = A, B, C, Z) represents the transition probability from message type X to message type Y.

Transition probability matrix (from row type to column type):

	A	B	C	Z
A	0.1	0.4	0.2	0.3
B	0.0	0.1	0.3	0.6
C	0.0	0.4	0.1	0.5
Z	0.2	0.0	0.0	0.8

Since the system is always to be traversed by only a single message at a time, the generation of a new message is controlled by the residence time of the preceding message in the system. This message source is a primitive model of a dialog. The message of type A is then to be interpreted as the beginning of a dialog. Types B or C are possible further queries, and type Z signifies the termination of the dialog and no activity at the data terminal equipment (DEE). In this dialog, the responses of the data processing installation (DVA) are thus taken into account only in an aggregate sense in the queries entered at the DEE.

Program:

Each message in the model is mapped to a transaction in GPSS. The program is divided into the following sections:

1. Non-executable definition section of the program

All variables in the program were defined in the definition section so that changes can be made easily. The transition probability matrix was mapped into Functions 1 through 4. From the 1st row of the matrix, for example, the following function results (the message types were assigned the identification numbers KZ = 1, 2, 3, 4):

Message type:          4      2        1
                                   |
Cumulative probability: 0.5       1.0
                  |
                  Transition probability from initial state to state 2.

The processing time at the DEE depends on the preceding and the current message type (display time on screen, typing time). This is shown in the following matrix (unit: ms):

Processing time at DEE — matrix (rows: originating message type; columns: generated message type):

Originating \ Generated	1	2	3	4
1	2000	1500	1000	300
2	0	130	90	300
3	0	1200	800	300
4	1700	0	0	1

The rows of this matrix are implemented as Functions 5 through 8.

Random deviations — for example in message length or processing times — around a mean value are generated using Function 9. Functions 10 and 11 are used to access message length and input time respectively.

Via the arithmetic expression in Variable 1, the function number of the required function for determining the processing time is calculated. Variable 2 is used to calculate the table number, and Variable 3 to calculate the transmission time.

The state at the beginning of the simulation is established in Savevalue locations 1 and 2. The initial message type is Z (KZ = 4), and the preceding message type was A (KZ = 1).

2. Executable section

The executable section is divided into the following subsections:

2.1 Generating the Transactions

The transactions are generated in the Generate block. Facility 3 controls their temporal succession, since the Generate block can only be exited by a transaction when Facility 3 is not busy. The transaction is delayed by the time the operator at the DEE requires to evaluate the response and type in a new message. If the new message type is Z, then the transaction is destroyed and Facility 3 is released. The new message type is determined from the preceding message type, which was stored in X1. The old message type is stored in X3 and the new one in X1.

The associated values are assigned to the parameters of the transaction: P1 the message type, P2 the message length.

2.2 Passing Through the Processing Units

The transaction enters the buffer (corresponding to Storage 1) of the DEE. The message is transmitted. Facility 2 models the bottleneck that arises because during a defined time span only a single message can be transmitted. The message is delayed by the transmission time. The storages and facilities are released. The transaction is destroyed.

2.3 Output

In addition to the standard statistical output in GPSS, further output was generated by the QUEUE block in front of storages and facilities. Using the Tabulate block and Tables 1 through 16, the number of all transactions that were assigned to a specific message type during the simulation was printed out. This enabled verification of the transition probability matrix.

4. Simulation of Two Mutually Controlling Message Sources for the Simulation of a Dialog

Model:

The two mutually controlling message sources correspond in the dialog to a data terminal (DEE) and a data processing installation (DVA). The DEE as message source generates messages of type A, B, C, Z (corresponding to beginning, continuation, and termination of the dialog), and the DVA generates messages of type A1, B1, or C1 (corresponding to the possible responses).

The dialog is initialized by the DEE with a message of type A. The message is sent to the DVA, where it generates — with certain probabilities — a message of type A1, B1, or C1, which is sent back to the DEE as a response and there generates a message of type A, B, C, or Z. If message type Z is generated, then the dialog is terminated and there is no activity at the DEE; otherwise the dialog continues. The successor type following type Z is either A or Z. The transition probabilities of the various message types are presented in the following two matrices.

I. Transition probability matrix from message types A, B, C to message types A1, B1, C1:

	A1	B1	C1
A	0.70	0.20	0.10
B	0.00	0.80	0.20
C	0.10	0.40	0.50

II. Transition probability matrix from message types A1, B1, C1 and Z to message types A, B, C and Z:

	A	B	C	Z
Z	0.10	0.00	0.00	0.90
A1	0.01	0.40	0.40	0.19
B1	0.00	0.50	0.20	0.30
C1	0.00	0.10	0.60	0.30

Program:

The dialog is a sequence of messages of various message types. The dialog is mapped in the program as a single transaction, to which various message types are assigned over the course of the dialog. Between two dialogs there is no activity at the DEE. This is represented by the generation of transactions with message type Z.

The program is divided into the following sections:

1. Non-executable definition section of the program

All variables in the program were defined in the definition section so that changes can be made easily. Matrix II of the transition probabilities was implemented as Functions 1 through 4, and Matrix I as Functions 9 through 11. Random deviations — for example in message length — around a mean value are generated using Function 7. Functions 5 and 12 are used to access message length; Function 6 for input time; Function 8 for processing time in the DVA; Function 13 for the generation time of the new message type in the DVA; and Function 14 for the time the operator at the DEE requires to evaluate the messages from the DVA. Variables 1 through 5 serve, in sequence, the following calculations: function number for the transition probabilities from A1, B1, C1 to A, B, C; table number; transmission time; function number for the transition probabilities from A, B, C to A1, B1, C1; and output time on the screen.

2. Executable section

The executable section is divided into the following subsections.

2.1 Generating the Transactions

The transactions are generated in the Generate block. Facility 1 controls their temporal succession, since the Generate block can only be exited by a transaction when Facility 3 is not busy. Parameter 1 of the transaction is assigned the identification number for the message type (A = 1, B = 2, C = 3, Z = 4; A1 = 1, B1 = 2, C1 = 3). If the message is of type A (beginning of a dialog), then the processing units are traversed; otherwise Facility 1 is released and the transaction is destroyed.

2.2 Passing Through the Processing Units

The message length is stored in Parameter 2 of the transaction. The message is delayed by the input time at the DEE and enters the output buffer of the DEE, which is represented by Storage 1. The message is transmitted. Facility 2 corresponds to the transmission unit of the DEE. The message is delayed by the transmission time. Storage 1 and Facility 2 are released. The message enters the input buffer of the DVA (Storage 2), occupies the processing unit (Facility 3), and is delayed by the processing time. The processing unit and buffer (Storage 2, Facility 3) are then released. The response messages are generated by assigning the new message types A1, B1, or C1 to the transaction. The message is delayed by the generation time, enters the buffer (Storage 3), occupies the transmission unit (Facility 4), and is delayed by the transmission time. The message enters the input buffer of the DEE (Storage 4), occupies the screen output unit (Facility 5), and is delayed by the output time. The message leaves the input buffer (Storage 2) and releases the output unit (Facility 5).

3. Output

[page 276: GPSS program listing — “SIMULATION OF MESSAGE SOURCES — GENERATING MESSAGE TYPE 1”]

The program listing for the first model (uncontrolled message source, single message type) appears on this page. The GPSS code defines:

FUNCTION RN1, C5 — a five-point continuous function approximating a normal distribution, with breakpoints at cumulative probabilities 0, 0.5, 0.84 (etc.), and corresponding function values.
VARIABLE 1: P2 * 2013 — arithmetic variable used for computing table numbers or transmission times.
TABLE M1, 100, 100, 9 — a frequency table definition.
Three GENERATE blocks (one per message source, TERMINAL 1, TERMINAL 2, TERMINAL 3), each generating transactions with inter-arrival times uniformly distributed around 15,000 ms ± 5,000 ms, with a population of 1,000 and priority 5:
- Source 1: GENERATE 15000, 5000, 0, 1000,, 5 — Assigns message type 1, length 500 (modifier FN1), delay 100 ms (modifier FN1); transfers to common processing section.
- Source 2: GENERATE 15000, 5000, 0, 1000,, 5 — Assigns message type 2, length 500 (modifier FN1), delay 100 ms (modifier FN1).
- Source 3: GENERATE 15000, 5000, 0, 1000,, 5 — Assigns message type 3, length 500 (modifier FN1), delay 100 ms (modifier FN1).
QUEUE 1 / *ENTER 1, P2 / DEPART 1 — Queue 1 generates statistical output of the queue before Storage 1 (the concentrator buffer). Storage 1 represents the concentrator buffer; capacity entered is *P2 (message length parameter).
QUEUE 2 / DEPART 2 — Queue 2 generates statistical output of the queue before Facility 1. Facility 1 represents the bottleneck (Side 1) whereby during a defined time span only one message can be transmitted.
*ADVANCE 3, 1 — Delays the message by the associated processing time (Parameter 3, with modifier FN1).
QUEUE 3 / DEPART 3 — Queue 3 generates statistical output before Facility 2. Facility 2 represents the bottleneck (Side 2) whereby during a defined time span only one message can be processed/transmitted.
ADVANCE V1 — Delays the message by the transmission time (computed via Variable 1).
*LEAVE 1, P2 / RELEASE 1 — Releases Storage 1 and Facility 1 after transmission is complete.

[Pages 277–283: GPSS Program Listings — Figure/Code Only]

The following pages (277–283) consist entirely of GPSS simulation program listings (roller punch cards / Rollerkarten). These are reproduced verbatim below with structural annotations.

Page 277 — GPSS Listing: Simulation of a Message Source Generating Multiple Message Types According to a Defined Statistical Distribution

Functions:

No.	Definition	Values
1	FUNCTION RN1,D3	0.21→1, 0.72→2, 1.0→3
2	FUNCTION RN1,D3	1→100, 2→500, 3→3000
3	FUNCTION RN1,D3	1→100, 2→50, 3→4
4	FUNCTION RN1,D5	0.→0.5, 0.4→0.5, 0.5→0.5, 0.5→1.0

Initial values:

INITIAL X1,0
Variable X1: VARIABLE X1+1
Variable X2: VARIABLE X2 (message length)

GENERATE: 1250, 5000, 0, 1000, , 3

Every 2nd transaction is immediately destroyed.

SAVEVALLE “ALLE”, 1, “2”

TEST E C,)I,ENC

Assignment of message type, message length, and the processing time associated with the message:

ASSIGN 1,FN1
ASSIGN 2,FN2,4
ASSIGN 3,FN3,4

Queue 1 generates statistical output of the queue before STORAGE 1.

COM QUEUE 1,1
STORAGE 1 corresponds to the concentrator buffer
ENTER 1,*2
DEPART 1,1

Queue 2 generates statistical output of the queue before FACILITY 1.

COM QUEUE 2,1
FACILITY 1 corresponds to the bottleneck of the channel; this arises because during a certain time interval only a single message can be sent.
SEIZE 1
DEPART 2
Delay the message by the associated processing time: ADVANCE *3,1

Queue 3 generates statistical output of the queue before FACILITY 2.

COM QUEUE 3,1
FACILITY 2 corresponds to the bottleneck; this arises because during a certain time interval only a single message can be processed.
SEIZE 2
DEPART 3
Delay the message by the associated transmission time: ADVANCE V1
LEAVE 1,*2
RELEASE 1
RELEASE 2
END TERMINATE 1
START 10000
END

Page 278 — GPSS Listing (continued, 69 Roller Punch Cards)

[page 278: figure/code only — continuation of roller punch card program listing]

Page 279 — GPSS Listing: Simulation of a Message Source Generating a Logically Interconnected Message Sequence — Transition Probabilities

Functions:

No.	Definition	Description/Values
1	FUNCTION RN1,D4	0.10→1, 0.5→2, 0.7→3, 1.0→4
2	FUNCTION RN1,D3	0.1→2, 0.4→3, 1.0→4
3	FUNCTION RN1,D3	0.4→2, 0.5→3, 1.0→4
4	FUNCTION RN1,D2	*0.5→1, 1.0→4
5	FUNCTION X1,L4 (processing time)	1→2000, 2→1500, 3→1000, 4→300
6	FUNCTION X1,L4	1→0, 2→130, 3→90, 4→300
7	FUNCTION X1,L4	1→0, 2→1200, 3→500, 4→300
8	FUNCTION X1,L4	1→1100, 2→0, 3→0, 4→1
9	FUNCTION RN1,C5 (normal distribution)	0.→0.5, 0.4→0.5, 0.5→0.5, 0.8→0.5, 0.84→1.0, 1.0→1.2
10	FUNCTION X1,L4 (message length)	1→50, 2→20, 3→10, 4→*
11	FUNCTION X1,L4 (input time)	1→2500, 2→1000, 3→500, 4→*

Variables:

Variable 1: X1+4 — calculation of the function number for determining processing time
Variable 2: 4*X3-4+X1 — calculation of the ambient number
Variable 3: P2*20/3 — calculation of the transmission time

Initial values:

INITIAL X1,4
INITIAL X2,1

Tables 1–16: all defined as TABLE X2,1,500,5

GENERATE 1,1,0,10000,,4

FACILITY 3 controls the temporal sequence of messages:

SEIZE 3
ASSIGN 2,X1

Page 280 — GPSS Listing (continued)

X3 stores X1 — message type of the preceding message.

SAVEVALLE 3,X1: X1 stores the new message type
SAVEVALLE 1,FN*2
Assignment of message type and message length to parameters *1 and *2:
- ASSIGN 1,X1
- ASSIGN 2,V1
- SAVEVALLE 2,FN*2
- ASSIGN 2,FNC,9 — delay the message by the associated processing time
- ADVANCE X2,FN9
- TABULATE V2
- TEST L 4,*1,END

Queue 1 generates the statistical output of the queue before STORAGE 2.

COM QUEUE 1,1
STORAGE 1 corresponds to the transmit buffer of the terminal (DEE)
ENTER 1,*2
DEPART 1,1

Queue 3 generates the statistical output of the queue before FACILITY 4.

FACILITY 2 corresponds to the bottleneck of the channel; this arises because during a certain time interval only a single message can be sent.

SEIZE 2
DEPART 3
The message is delayed by the transmission time:
- ADVANCE V3
Release STORAGE and FACILITIES:
- LEAVE 1,*2
- RELEASE 2
- END RELEASE 3
- TERMINATE 1
- START 10000
- END

(102 roller punch cards)

Page 281 — GPSS Listing: Simulation of 2 Mutually Controlling Message Sources for Modeling a Dialog

Variables:

No.	Expression	Description
1	V1: 1+X1	Calculation of function number for transition probabilities from A1,B1,C1 to A,B,C
2	V2: 4*X3-4+X1	Calculation of the table numbers
3	V3: P2*2/3	Transmission time
4	V4: X1+8	Calculation of function number for transition probabilities from A,B,C to A1,B1,C1
5	V5: P2*10	Output time on the display screen

Functions:

No.	Definition	Description
1	FUNCTION RN1,D2	Determines message type upon generation of a transaction A or Z: 0.10→1, 1.0→4
2	FUNCTION RN1,D4	Determines message type A,B,C,Z depending on type of preceding message (which was of type A1,B1, or C1): 0.01→1, 0.41→2, 0.81→3, 1.0→4
3	FUNCTION RN1,D3	0.5→2, 0.7→3, 1.0→4
4	FUNCTION RN1,D3	0.1→2, 0.7→3, 1.0→4
5	FUNCTION X1,L3 (message length assignment for types A,B,C)	1→50, 2→20, 3→10
6	FUNCTION X1,L3 (input time assignment)	1→2500, 2→1000, 3→
7	FUNCTION RN1,C5 (random deviation, normal distribution)	0.→0.5, 0.8→0.16, 0.9→0.5, 0.84→1.0, 1.1→1.2
8	FUNCTION X1,L3 (processing time in the terminal (DEE), for types A,B,C)	1→20, 2→15, 3→10
9	FUNCTION RN1,D3 (transition probabilities from A,B,C to A1,B1,C1)	0.7→1, 0.9→2, 1.0→3
10	FUNCTION RN1,D3	0.0→1, 0.8→2, 1.0→3

Page 282 — GPSS Listing (continued)

No.	Definition	Values
11	FUNCTION RN1,D3	0.1→1, 0.5→2, 1.0→3
12	FUNCTION X1,L3 (message length for types A1,B1,C1)	1→100, 2→40, 3→20
13	FUNCTION X1,L3 (origination time for A1,B1,C1)	1→10, 2→8, 3→5
14	FUNCTION P1,L3 (processing time at the terminal (DEE) operator, for types A1,B1, and C1)	1→250, 2→100 (implied), 3→25

Tables 1–16: all defined as TABLE P1,1,4,5

GENERATE 1,1,0,15000,,C

SEIZE 1
Assignment of parameter 1 or 4: ASSIGN 1,FN1
TEST E 1,P1,END
SAVEVALUE 1,P1
SAVEVALUE 3,4
TRANSFER ,CON2

Assignment of parameter 1 depending on replies A1,B1,C1:

CON1: SAVEVALUE 3,P1
ASSIGN 2,V1
ASSIGN 1,FN*2
SAVEVALUE 1,P1
TABULATE V2
TEST NE 4,P1,END

Passing through the processing units after assigning the required parameters:

CON2: ASSIGN 2,FN5 — assign message length
ADVANCE FN16,FN1 — input time on the terminal (DEE)
ENTER 1,*2 — characters are stored in the output buffer of the terminal (DEE)

Page 283 — GPSS Listing (continued)

SEIZE 2 — transmit unit of the terminal (DEE)
ADVANCE V3 — transmission time
LEAVE 1,*2
RELEASE 2

Processing in the remote data processing unit (OVA):

ENTER 2,*2 — input buffer of the OVA
SEIZE 3 — processing unit of the OVA
ADVANCE FN8,FN1 — processing time
LEAVE 2,*2
RELEASE 3

Generating the reply and assigning the new parameters:

ASSIGN 2,V4
ASSIGN 1,FN*2
SAVEVALUE 1,P1
ASSIGN 2,FN12,7 — message length
ADVANCE FN13,FN1
ENTER 3,*2
SEIZE 4 — transmit unit of the OVA
ADVANCE V3 — transmission time
RELEASE 4
LEAVE 3,*2

Processing in the terminal (DEE):

ENTER 4,*2 — input buffer of the terminal (DEE)
SEIZE 5 — output unit for the display screen
ADVANCE V5 — output time
ADVANCE FN14,FN7
LEAVE 4,*2
RELEASE 5
TRANSFER ,CON1

END:

RELEASE 1
TERMINATE 1
START 15000
END

Simulation of Core Memory Allocation in an Electronic Data Processing System

W. Kistler, IBM Deutschland

Subject

The subject of these considerations is a stochastic simulation model with analytical elements, developed and deployed for performance improvement of a data processing (EDP) system. Under certain preconditions it is also usable during the planning phase.

Simulation Objective

Multiprogramming operation on an EDP installation can be run with either a fixed or a variable number and size of core memory areas (regions) that are made available by the operating system to application programs during their execution phase. Each of the alternatives exerts a particular influence on throughput, program residence time, main memory utilization, and the time required to allocate the necessary core memory space to programs of various sizes (core allocation). The factors mentioned are influenced — beyond the hardware configuration and the nature of the program load — by the number of programs simultaneously activated and thus competing for main memory space and other system components.

Page 285

This number is to be optimized, and the advantages and disadvantages of fixed versus variable regions are to be quantified. The results of the simulation form the basis for a decision on the most favorable core memory concept under which the data processing system can be operated.

System Analysis

In an electronic data processing installation operating under multiprogramming in batch mode, programs arriving as a “job stream” are assigned core memory areas by the operating system according to a defined procedure; the programs then occupy these areas during their execution phase (run time). The mean run time of a representative program depends, among other things, on the hardware configuration and on the number of competitors for the system components.

With a configuration using fixed region sizes (and numbers), jobs (a job being a series of logically interdependent programs) are directed into regions sufficient for the largest program in the job. For the other programs, capacity losses then arise. However, there are no time delays in memory allocation for successive programs, since the region size released by the preceding program is also sufficient for every subsequent program in the job. In the variable-region-size concept, each program is allocated only the space it actually needs. Core memory is thus better utilized. On the other hand, job residence times become longer, since it frequently occurs that subsequent programs must wait for memory space because they are larger than the released region or because programs of parallel jobs have already been waiting longer and therefore claim the region with higher priority.

Page 286

Of particular significance in these processes are the “initiators.” They initiate the execution of jobs in the system; their number influences both the extent of parallel processing and the delay in core allocation for larger programs. If more initiators are activated than programs can fit in main memory, memory is better utilized, since for gaps that would arise because the next program is too large, one of the “waiting” initiators often has a suitable program. On the other hand, this reduces the chance for larger programs to find a sufficiently large contiguous memory area; their execution is delayed and job run times become longer.

The allocation of main memory space to programs by the operating system follows certain criteria that can be found in the systems literature. Insofar as they influence the course of the simulation, these functions are to be modeled with appropriate resolution.

Model Description, Model Synthesis

Given is a representative stream of programs in which each program is characterized by its core memory size and run time. The programs are provided with main memory space for the duration of their run time according to a defined procedure. Among other things, the functions of “fixed” and “variable region partitioning” and the “buffer effect” of excess initiators are to be modeled. During the simulation run, the memory location, memory time (start, end), and delay in allocation are to be logged for each program; at the end, data for production time (enabling inference about throughput), memory utilization, and total allocation delay are to be output.

Page 287

The run time of a program is a very complex function of all system components, which also depends strongly on the type and extent of parallel processing (multiprogramming).

When processing a program load, run times arise that are typical only for the conditions prevailing at that moment. In the simulation, the times would have to be modified. This would require modeling the data processing system in many details — the effort would be very large. If, however, a simple algorithm for correcting the times can be found, this difficulty can be circumvented. For model synthesis, the following special problems must therefore be solved:

Determination of the program sizes of a representative workload.
Determination of the corresponding program run times in an electronic data processing installation serving as the reference system.
Determination of the correction factors for adapting run times to the simulated system and to the current extent of parallel processing at the time of program execution.

The simulation concerns an already existing EDP system that is to be optimized with the aid of the model. Part of the operating system is a software monitor (SMF — System Management Facilities) that continuously collects data for various purposes, providing information about the activity and status of the installation. Among the data collected are the sizes and run times of executed programs. Thus the data mentioned under points 1 and 2 are available as model input; only a representative selection needs to be made.

Page 288

The determination of the correction factors cited under point 3 proceeded as follows: The system from which data were collected for characterizing the programs is in this case identical with the system to be simulated. Consequently, adaptation to changed hardware and software can be omitted. The problem thus reduces to the following question: How does the run time of a program change in a data processing system as a function of the number of concurrently activated programs with which it must compete for the system components? For the simulation objective it is unimportant to know how the influence of the special characteristics (I/O- or CPU-intensive?) of the programs running in parallel at the given time affects this — mean values suffice. These values can, for example, be determined with a hardware measurement instrument that permits the system throughput (indicator: CPU activity in problem state) to be ascertained as a function of the number of “simultaneously” active regions. Via a simple conversion, the run time can then be related to the throughput. The relationships thus obtained are built into the model as a formula or table and represent the influence of all system components on program run time. This procedure not only avoided the laborious modeling of numerous system functions, but also achieved a relatively short run time of the programmed model.

A factor that strongly influences the model run time is the type of simulation of the time progression. One can use the time steps of a simulated clock to trigger model activities. However, with a sufficiently small step size, many clock steps would elapse in this model with no or only insignificant operations as a consequence.

Page 289

It appeared more favorable and entirely sufficient for the required accuracy to use only the events “program end.” This choice is meaningful, since only after such an event can new allocations be attempted.

Although the residence time of programs in main memory must then be determined in advance at the time of their activation, according to the situation prevailing at that moment, and cannot subsequently be derived from the continuously changing environmental influences, the error can be neglected.

Implementation Aids

For the programming of the model, in addition to the usual languages, special simulation languages such as GPSS (General Purpose Simulation System) and CSS (Computer System Simulator) were available. Their use would have meant, however, that handling of the model through batch-oriented processing would have become more cumbersome. Since the described modeling method had kept the expected programming effort within limits, the possibility presented itself to forgo special simulation languages and to use APL\360.

APL\360 is a time-sharing-oriented system for interactive processing at a terminal with a programming language that is distinguished by simple syntax and capable language elements and is particularly suitable for mathematical applications. The programs are processed interpretively during execution; conversion is not required. The application promised considerable advantages:

Page 290

Programming and testing can be carried out at the terminal considerably faster than with batch processing.
Modifications can be carried out more quickly and checked immediately.
Model runs can be performed in rapid succession in large numbers with changed inputs.

The only disadvantage of APL is that it has no file processing capability and therefore could not access the SMF records available in the system for machine-based selection and processing. Consequently, the numerous data characterizing the programs that constituted the model input had to be entered via the terminal keyboard.

Test and Validation

During programming, the individual program modules were already tested at the terminal. The completed programmed model was subjected to a functional test, followed by an extensive verification phase. All apparently possible situations were run through. Since the model logs the allocations in full detail, it was easy to check whether the rules governing the process were being adhered to correctly. The correct modification of program run times could also be checked easily in this way. Finally, a run with a large number of real data verified whether the sum of all run-time modifications — taking into account the mean degree of parallel processing achieved — corresponded to the value to be expected according to the measurements with the hardware monitor mentioned above.

Page 291

Effort, Achievements, Experience

The effort for design, implementation, and testing of the simulation model amounted to approximately 6 weeks. Hardware measurements are not included in this; the data required for this model were a byproduct of measurements made for other purposes. The time required for the actual simulation runs (approx. 30) amounted to a further week.

The model runs enabled a quantitative comparison of the advantages and disadvantages of fixed and variable regions. The specific results were important for decisions regarding the present system but cannot naturally be transferred to other conditions. Some more general remarks can, however, be made.

Variable regions lead to a throughput gain that in special cases can be considerable (e.g., with high core memory occupancy, low CPU and I/O utilization, very different program sizes), but then also cause a delay in core memory allocation and thus a lengthening of job residence times. This does not increase the load on the system, since the “waiting” programs are not in core memory, but for jobs with larger programs the delay may under certain circumstances become unacceptable (deadline work!). Special measures must then be taken that interrupt normal operations (losses) and secure the required space for these programs. If the throughput gain proves to be small — for example because the overall system is already heavily loaded — it may be possible to save core memory space at the same throughput. If the delays are unacceptable, fixed regions offer the better concept.

Page 292

The model also offers the possibility of optimizing the number of initiators such that an acceptable ratio between throughput (or core memory requirement) and job run-time extension is achieved.

The operational and user-friendliness of the model is particularly high due to the use of APL: a user unfamiliar with the model quickly becomes acquainted with its operation, not least because all inputs are requested individually and intelligibly via the terminal. In the event of aborts caused by line errors or certain hardware failures, the running simulation is not lost but is saved to a backup area, so that after elimination of the abort cause the run can be continued.

Summary

The presented simulation model offers an example of how, by combined use of various methods (data recording and evaluation, measurements) and a programming language suitable for the special case, the run time of the model as well as the implementation effort could be kept low. System analysis and model deployment yielded important findings and information that could not have been obtained through experiment, or only with great effort. They enabled the decision for the optimal core memory concept on a secure basis.

Simulation of Computer Networks with Clocked Information Transfer

U. Herzog, G. Kampe, and M. Langenbach-Belz Institute for Message Switching and Data Processing (University of Stuttgart)

1. Introduction

In computer networks or computer-controlled data or telephone networks, information must be exchanged both between the individual computers and between a computer and its associated peripherals. The information must pass sequentially through various structural units (e.g., registers), whereby it experiences waiting times and further processing times before its final processing. In real-time systems, strict requirements are placed on such waiting times — that is, the time between the generation of a piece of information and its final processing should not exceed a defined maximum value, or should do so only in a small percentage of all cases. In order to check whether the requirements placed on a planned system are met, as well as to find and eliminate bottlenecks, it is necessary to analyze the traffic flow (of information) through the system and to determine waiting times, memory loads, etc. The complex fine structure of such networks and the dependencies of information items on one another that sometimes occur frequently make it impossible to calculate the traffic flow exactly using traffic-theoretic methods. Therefore, in studying the described problem domain, alongside approximate calculations, simulation is largely relied upon — that is, network structure and traffic flow are modeled on a digital computer (cf. also /2/). But simulation too cannot be applied without limitation. For example, even on the largest data processing installations it is often impossible — due to memory space requirements — to simulate the systems described above as a whole. Furthermore, due to the complexity of the simulation programs, program run times would become unacceptably large. Finally, it should be noted that simulation programs should also possess a certain degree of clarity (simpler and more intelligible documentation) and should be able to be reliably tested with manageable effort. For these reasons it is meaningful to subdivide an overall system (complete network) into individual, smaller subsystems and then to simulate the individual subsystems. A problem arising here is the choice of interfaces between the subsystems. In particular, the modeling of the traffic occurring at the interfaces is of special importance, since the characteristic properties of these substitute traffic patterns (e.g., interarrival-time distribution function) exert a substantial influence on the characteristic traffic quantities (e.g., memory loads, waiting times, etc.) of the simulated subsystems.

Page 294

On the one hand, the substitute traffic patterns should be realizable as simply as possible in the simulation model; on the other hand, they should not cause distortions of the results when simulating a subsystem compared to simulation of the overall system.

In the following sections, the fundamental structure and traffic of the investigated overall networks are first described. This is followed by the division of the overall network into subsystems. The interface problems arising here are explained using the example of one interface. It is shown how, for this interface, a substitute traffic pattern was found through systematic investigation that is similarly simple to realize simulation-technically as Poisson traffic and that yields very realistic results.

It should be noted at this point that this report does not intend to show model building in detail (cf. for this /1/, /2/, /3/, /4/) or to give a description of the realized, extensive simulation program. Rather, some fundamental thoughts and experiences are set forth that arose during the creation of the program.

2. Structure and Traffic of the Investigated Networks

2.1 Structure

The fundamental structure of the investigated networks is shown in Figure 1.

[Figure 1: Fundamental structure of the investigated networks — showing central units (computers), data transmission channels, peripheral units, and remotely located peripheral units]

The units shown in simplified form in Figure 1 — such as the central unit (computer), data transmission channels, and peripheral units — in reality consist of multiple waiting memories (registers) and service units.

The central units are interconnected with each other via a pair of unidirectionally directed data transmission channels. Peripheral units can be connected per central unit either directly or via data transmission channels (remotely located peripheral units).

[p. 295 — continued]

As a practical example of the occurrence of such network structures, one may cite networks for control information in future and currently-under-development computer-controlled telephone networks. The entities involved may also be computer networks in which the peripheral units can correspond, for instance, to terminals, background storage devices, or even satellite computers.

2.2 Traffic

The traffic flow in the network is determined, apart from the fine structure of the network itself, by the generation process of information (requests), the service process in the individual service units, and the queuing disciplines at the individual queues. These processes and disciplines must be modeled in the simulation model as faithfully as possible to match the actual conditions (cf. /2/).

In the network shown in Figure 1, various types of requests arise randomly in the peripheral units. The inter-arrival intervals between two requests are described by a negative-exponential distribution (“Poisson arrivals”), which represents a good approximation for most cases encountered in practice (as known from measurements). The requests arising in the periphery are brought to the central unit (computer), where, after a possible waiting time, they are processed by a service unit. The processing of a request by the service unit of the central unit may give rise to further messages to the periphery or to the other central units, which in turn may cause further acknowledgment messages, etc. (follow-up information). These mutual dependencies of information items give rise to a kind of “feedback information flow” between the central unit and the periphery, or equivalently, a mutual influence of the traffic flows on the data transmission channels.

The service unit of a central unit requires a specific, constant time per information type (“original requests” and “follow-up information”) for processing requests.

In many systems, the transfer of information between the data transmission channels (or the peripheral units) and the central units is clock-controlled, i.e., it occurs only at specific, fixed time instants. For example, the central unit always checks at clock-tick instants whether any requests are waiting on the connected data transmission channels or in the peripheral units to be taken over into the central unit. This mode of operation can result in multiple requests arriving at the central unit simultaneously at clock-tick instants (batch arrivals).

3. Decomposition into Subsystems

As already explained in more detail in Section 1, it is for various reasons either impractical or even impossible to simulate the entire network as a whole. A decomposition into subsystems is therefore necessary, for each of which a separate simulation model and program is created.

When decomposing into subsystems, care should be taken that the individual subsystems represent self-contained systems as far as possible — that is, that they have as few interfaces to other subsystems as possible. This generally ensures that an individual subsystem depends on as few parameters of the other subsystems as possible.

[p. 296]

For the network structure shown in Figure 1 and the data traffic described in Section 2.2, a division into three partial models is therefore advisable (cf. also Figure 1):

Data traffic between two central units
Data traffic between a central unit and directly connected peripheral units
Data traffic between a central unit and peripheral units connected via data transmission channels (remote peripheral units)

[Figure reference: peripheral units, remote peripheral units — see Figure 1]

In each of these partial models, the interface to the other partial models lies at the central unit (cf. also Section 4). The traffic flow arriving at this interface from those parts of the network that are not simulated in detail — i.e., from the other partial models — must be represented by a “substitute arrival process” that corresponds as closely as possible to reality. Of particular interest is how simplifications of the substitute arrival process (such as, for example, neglecting the correlation of follow-up information) affect the characteristic traffic quantities of the partial model. For partial model 1, “Data traffic between two central units,” Section 4 shows — using the interface between the central unit and the periphery as an example — how a suitable substitute arrival process was found through systematic investigation.

The simulation results of all subsystems must ultimately be checked for mutual consistency. For the partial models described above, one of several possible checks is provided by the fact that a central unit is included in all partial models. If one assumes the same total traffic load for all three partial models, then comparable values must result for queue occupancy, mean waiting time, etc. in the central unit for all three models. Otherwise, the partial models must be subjected to modification.

From the simulation results of all subsystems, conclusions about the overall system can then be drawn (although the interdependence of the individual subsystems must not be disregarded!).

4. Example of the Representation of Traffic Flow at a Subsystem Interface

In this section, using partial model 1 “Data traffic between two central units” and the interface between the central unit and the periphery as an example, it is shown how a suitable substitute arrival process was found (cf. Figure 2).

[p. 297]

Figure 2: Partial model “Data traffic between two central units.” The portions represented by the substitute arrival process (periphery 1 and periphery 2) are indicated schematically. Data transmission channels connect the central unit (Zentraleinheit) to both peripheral groups.

The following investigation uses a series of progressively simplified models to examine how the substitute arrival process (cf. Figure 2), which is to represent the traffic flow coming from the periphery, must be chosen. The underlying objective is to realize this substitute process in the simulation as simply as possible, while at the same time not distorting the traffic flow between the central units.

4.1 Detailed Interface Model (Model 1)

In order to investigate the influence of simplifications of the substitute arrival process from the periphery on the waiting times in the central unit, it is first necessary to establish and simulate a model for the data traffic between periphery and central unit as a starting point. Figure 3 shows an example of such a model.

Figure 3: Model for data traffic between central unit and periphery (Model 1). The clock-controlled exchange of information between the data transmission channel or periphery and the central unit is represented by the switches labeled “clock” (Takt). Per clock tick, at most 1 request is taken from each buffer.

Legend: PP = buffer in periphery; EP = input buffer (Eingabe-Puffer); APP = output buffer for periphery (Ausgabe-Puffer für Peripherie); APD = output buffer for data transmission channel; B = service unit (Bedienungseinheit); PD = buffer on data transmission channel side.

[p. 298]

In periphery 1, requests arise (“original requests” in Figure 3) with negatively-exponentially distributed inter-arrival intervals; these must wait in PP (cf. Figure 3) until they are collected by the clock. After their transfer into EP of central unit 1, they are processed by service unit B after a possible waiting period. If the processing of a request results in follow-up information addressed to central unit 2, this is subsequently written into APD. Correspondingly, follow-up information addressed to periphery 1 is written into APP. Finally, it is also possible that the processed request generates no further follow-up information at all. These three different possibilities are indicated in Figure 3 by the branching point below the service unit. A similar branching point is located after the clock-controlled extraction of information from APP. Either the information extracted from APP results in no further acknowledgment to the central unit, or it results in a direct acknowledgment that is written into EP (e.g., confirmations that certain information items have left the central unit), or it results in an acknowledgment to the central unit only after a certain delay time V in the periphery, which is then written into PP. This produces a feedback queuing system that accounts for the temporal correlation of the individual follow-up information items as well as the clock-controlled transfer of information from the periphery.

It should also be mentioned that Figure 3 shows only the possible paths of the traffic flow in principle. In the actual simulation, a substantially more detailed distinction was made between different information types (up to 13 types), and their path through Model 1 was uniquely defined.

As is evident from Figure 3, all information arriving at central unit 1 is stored intermediately in the common EP and processed one after another by a single service unit B. This means that the traffic flow of interest (1) from central unit 2 to central unit 1, as well as the traffic flow (5) from central unit 1 to central unit 2, is influenced by the traffic flows (2), (3), and (4) in central unit 1. For example, the waiting times of information items of traffic flow in EP depend, among other things, on the arrival rates and service times of information items of traffic flows (2), (3), and (4). As an evaluation criterion for the quality of a substitute arrival process that is intended to represent traffic flows (3) and (4), the mean waiting time of information items in EP was therefore chosen.

In order to investigate the principal influences of a substitute arrival process on the mean waiting time in EP, it is not strictly necessary to use the exact arrival process at PD for the information coming from central unit 2. For simplicity, a Poisson arrival process with arrival rate λ (arrivals per unit time) was therefore assumed for this arrival process at PD.

With a view to the intended substitute arrival process at EP for traffic flows (3) and (4), the following quantities were measured during the simulation of Model 1: in particular, the mean waiting time w of information items in EP of the central unit (cf. Figure 7, Curve 1) as well as the distribution of inter-arrival intervals of the information arriving at EP from traffic flows (2), (3), and (4) (cf. solid line in Figure 4).

During the measurement of the inter-arrival interval distribution, it was found that the measurement points at integer multiples of the clock period (cf. crosses in Figure 4) can, in a semi-logarithmic plot, be connected to a very good approximation by a straight line (cf. dashed line in Figure 4).

[p. 299]

As a first approximation, the inter-arrival intervals in question were therefore regarded as mutually independent and negatively-exponentially distributed, instead of the clock-controlled arrivals. This led to the strongly simplified model described in Section 4.2.

Figure 4: Measured values of the inter-arrival interval distribution P{a > t} of information from traffic flows (3) and (4) at EP in Model 1 (cf. Figure 3). Clock period T = 5 time units.

Parameter A = load offered to service unit = Σ λᵢ hᵢ Erlang, where λᵢ = arrival rate of information type i; hᵢ = service time of information type i.

Curves shown for A = 0.14 and A = 0.43.

4.2 Strongly Simplified Model (Model 2)

In the strongly simplified model shown in Figure 5 (Model 2), the entire feedback loop shown in Figure 3 is omitted, and the arrival process at EP originating from traffic flows (3) and (4) is replaced by a Poisson arrival process with the same arrival rate (cf. end of Section 4.1). The clock-controlled transfer of information from PP and APP into EP is thus neglected. For information items of the substitute arrival process, a random number is used when they are transferred from EP into the service unit to decide which information type it should be. The temporal correlation of the follow-up information is thus neglected.

Figure 5: Strongly simplified model for data traffic between central unit and periphery (Model 2). Abbreviations as in Figure 3.

The substitute arrival process (Ersatz-Ankunftsprozess) replaces flows (3) and (4). The feedback path is severed and not further tracked. The data transmission channel (1) from central unit 2 retains its clock-controlled connection to EP.

[p. 300]

A comparison of the simulation results for the mean waiting time w in EP of Model 1 and Model 2 showed that the approximation with Model 2 yielded only very rough and in some cases unsatisfactory results compared to Model 1 (cf. Figure 7, Curve 2). A better approximation than a Poisson arrival process therefore had to be sought. This improved approximation is explained in the next Section 4.3.

4.3 Improved, Simplified Model (Model 3)

In the improved, simplified model (Model 3), the structure of Model 2 was retained (cf. Figure 5), and the temporal correlation of the follow-up information within the substitute arrival process was also neglected. However, the clock-controlled transfer into EP was now taken into account for the substitute arrival process.

The measured inter-arrival interval distribution from Model 1 is a step function whose breakpoints at integer multiples of the clock period lie approximately on a straight line in a semi-logarithmic plot (cf. solid line in Figure 4). The step function results from the clock, since information can only arrive at the input buffer at clock-tick instants, and the inter-arrival intervals can therefore only assume discrete values, namely integer multiples of the clock period. It is also noteworthy that the probability of an inter-arrival interval > 0 is not 1 but rather < 1. The reason for this is that per clock tick, multiple information items can be transferred into the input buffer (batch arrivals).

For the distribution of inter-arrival intervals of the substitute arrival process, a step function was therefore used instead of the Poisson process in Figure 4. The implementation of this step function in the simulation program could in principle be achieved by specifying a look-up table that transforms a uniformly distributed random variable into an arbitrarily distributed random variable. However, the application of this approach appeared unsuitable for the following two reasons:

Each determination of an inter-arrival interval would have required an access to the look-up table. Since such an access requires relatively substantial computation time, the run time of the entire simulation program would have been considerably increased.
In order to even enter a look-up table, a large number of value pairs (inter-arrival interval / probability) for the step function would have been required for each load case. The difficulty would then have been in obtaining appropriate numerical values for these value pairs.

It was therefore aimed at generating the step distribution in the simulation in a manner similarly simple to that for the negative exponential distribution. These considerations led to the following approximation:

As already mentioned above, the lower breakpoints of the step function lie approximately on a straight line in a semi-logarithmic representation. An exponential function is therefore assumed as the “lower bounding curve” of the step function. This exponential function is, however, placed not at 1 but at q < 1 at t = 0, in order to account for the batch arrivals (cf. Figure 6).

[p. 301]

Figure 6: Simulated distribution function P{a > t} of inter-arrival intervals of the substitute arrival process.

The bounding curve is q · e^(–t/a₀). The step function (simulated distribution function) follows the bounding curve at discrete multiples of the clock period T. The determination of the instantaneous inter-arrival interval starts from a uniformly distributed random number between 0 and 1: if the random number falls between q and 1, the inter-arrival interval is set to 0 (batch arrival); if it falls between 0 and q, a corresponding time t’ is calculated from the bounding curve, then rounded up to the nearest integer multiple of the clock period and used as the instantaneous inter-arrival interval.

The instantaneous inter-arrival interval is determined as follows: starting from a uniformly distributed random number between 0 and 1. If this random number lies between q and 1 (cf. Figure 6), the instantaneous inter-arrival interval is set equal to 0 (i.e., a batch arrival takes place). If the random number lies between 0 and q, a corresponding time t’ is computed analytically as in the case of a Poisson offer, but here using the bounding curve q · e^(–t/a₀) (cf. dashed arrows in Figure 6). The value t’ thus found is rounded up to the nearest integer multiple of the clock period and used as the instantaneous inter-arrival interval. In this way, the step function is realized in the simulation in a manner similarly simple to the Poisson offer.

The only remaining question is how to choose the values q and a₀ of the bounding curve for a given load case. The following considerations can be carried out for this purpose:

The actual mean inter-arrival interval a_m of the information items must be equal to the mean of the step curve in Figure 6. However, this actual mean inter-arrival interval a_m can also be formally computed from the bounding curve. It is:

$$a_m = \frac{q \cdot T}{1 - e^{-T/a_0}}$$

where T = clock period. (1)

If the actual mean inter-arrival interval a_m and the value q are given, then the value a₀ for the bounding curve follows from equation (1) as:

$$a_0 = \frac{-T}{\ln!\left(1 - q \cdot \frac{T}{a_m}\right)}$$ (2)

To compare the results of Model 1 and Model 3 described above, the value of q was in each case taken from the measurement results of Model 1 (probability of an inter-arrival interval > 0) for each load case. It was found that the results of the simplified Model 3 agreed very well with the results of the detailed Model 1 (cf. Figure 7, Curve 3). This means that the temporal correlation between the arrivals of the follow-up information items (which was not accounted for in the simplified model) has a negligible influence on the results. The principal influence comes from the clock-controlled arrival process and the batch arrivals caused by it.

[p. 302]

This was also reflected in the fact that the results of Model 3 depend strongly on the chosen value of q. It should also be noted that for a given value a_m, equation (2) yields the requirement q < a_m / T.

The substitute arrival process described above can now be used in partial model “Data traffic between two central units” (cf. Figure 2), by employing it there to faithfully replace the traffic flow from the periphery to the central unit. For each load case, only 2 parameters are needed for the substitute arrival process: the actual mean inter-arrival interval a_m and the value q. The value a₀ for the bounding curve is then computed from equation (2) within the simulation program itself.

Figure 7: Mean waiting time w of all information items in EP as a function of the load A offered to the service unit. Service time of all information types uniformly h = 2 time units. Clock period T = 5 time units.

Curve (1): Model 1 (Section 4.1)

Curve (2): Model 2 (Section 4.2)

Curve (3): Model 3 (Section 4.3)

(Axes: w [time units] vs. A [Erlang])

[p. 303]

5. Summary and Outlook

This report presents several fundamental considerations on the simulation of computer networks with clock-controlled information transfer. The goal of the simulation, carried out in SIMSCRIPT (cf. /1/, /2/), was to analyze the traffic flow in the networks (determination of queue occupancies, waiting times, etc.) and to identify bottlenecks.

Due to the complexity of the network considered as well as in the interest of better clarity in the simulation programs, it was necessary to decompose the overall system into individual partial models. This decomposition into partial models gave rise to interface problems, particularly regarding the traffic flows occurring at these interfaces. Using the interface of one partial model as an example, it was shown how important the assumption of suitable (simple yet accurate) substitute arrival processes — for those parts of the network not simulated in detail — is for the simulation. Using a series of progressively simplified models, a substitute arrival process was found that, on one hand, is very simple to realize in the simulation, and on the other hand, faithfully reproduces the real conditions.

It should also be mentioned that the simulation results obtained were additionally used to check the accuracy and validity of analytical approximation calculations for the traffic flow that were carried out in parallel.

Further investigations, which are currently still in progress, deal in particular with the problem of “overhead times” (Verwaltungszeiten) in the central units. Simulation is again used to analyze how overhead times (e.g., input/output management times at clock-tick instants) affect the traffic flow.

References

/1/ Kampe, G.: Simscript. Vieweg-Verlag, Braunschweig, 1971.

/2/ Kampe, G.; Kühn, P.; Langenbach-Belz, M.: Simulation in der Nachrichtenverkehrstheorie: Problemstellungen und Programmiersprachen. Workshop über Methodik der rechnergestützten Simulation, 10.5.–11.5.73, Karlsruhe.

/3/ Huber, M.; Wagner, W.: Simulation von Nachrichtenvermittlungssystemen. In: Nicht-numerische Informationsverarbeitung, ed. R. Gunzenhäuser, Springer-Verlag, Wien–New York, 1968.

/4/ Wagner, H.; Dietrich, G.: Bestimmung der Verkehrsleistung von Wartesystemen durch künstlichen Fernsprechverkehr. NTZ, 17 (1964) 6, pp. 273–279.

/5/ Kümmerle, K.: Ein Vorschlag zur Berechnung der Vertrauensintervalle bei Verkehrstests. A.E.Ü., 23 (1969) 10, pp. 507–511.

Note: Special thanks are owed to Dipl.-Ing. Otto Neff and Dipl.-Ing. Gebhard Thierer, who actively contributed to the investigations described in this report as part of their diploma theses.

[p. 304]

Simulation of Computer Network Systems — System Analysis and Model Synthesis

by Oswald Drobnik

1. Introduction

A computer network system (computer network) /1/, /2/, /3/ is a set of mutually connected, dependent or independent computer systems that communicate with one another under the direction of a network operating system (network control system), in order to share certain resources such as programs or data and/or to equalize load differences and satisfy reliability requirements. Many of the problems arising in the construction and operation of such systems — such as the selection of suitable network control structures, the determination of efficient job-scheduling algorithms, the assurance of specified job response times, and the prediction of system behavior in the event of failure of network components — cannot, due to their multilayered nature, be addressed by computational (analytical) methods but only by means of simulation. The aim of this contribution is to consider general aspects of the simulation of computer networks with a view to developing discrete simulation models that are conceived for solving complex problem classes and can be tailored to the investigation of individual problems without great effort.

2. System Analysis

The system to be simulated consists of the computer network system and its communication with the environment, expressed in the acceptance and processing of jobs. System analysis is not confined solely to describing the components of the computer network (see /4/), possible decompositions into subsystems, and their interactions, but also encompasses the characterization of the job stream to be processed and the compilation of performance measures such as system residence time of jobs, throughput, etc., which can be used to determine the system’s performance capability or system behavior.

[p. 305]

Of essential significance in the transformation process from a system model — as the result of system analysis — into a simulation model to be implemented is the manner in which the system model is described. Graph models recommend themselves not only because of their clarity in representing the interactions of functional units, but above all because of the existence of formal methods, e.g., for finding an equivalent minimal system or for deciding on the determinacy of the system.

From a job-specific viewpoint, the system can be described as a network of queues and service stations representing the functional units. The course of events in the system then appears to a job as a sequence of waiting and service phases. The system is characterized /5/ by the network structure, the distributions of the arrival and service processes, the capacity of the waiting rooms, the queuing disciplines, and any supplementary descriptions of job processing. This model illustrates in particular the competition among the jobs present in the system for the service stations (see Appendix, Figure 1).

For a description of the computer network that is oriented more toward the interactions of components, one proceeds from the definition of the active computer network proposed in Bell /1/ as a set of interacting processes. A process is thereby understood as the execution of a function in its environment (active phase of a functional unit) — e.g., the execution of a program in a specific computer system.

The interaction of processes manifests itself explicitly in the exchange of messages or implicitly in the competition for the limited resources available in the system. This makes possible a formulation

[p. 306]

of the computer network as a general resource system in the sense of Holt /6/, which is composed of: the reusable resources (storage media, files), the consumable resources (messages between processes), and specifications of the domains and effect ranges of the processes and their logical dependencies. The influence of externally arriving jobs manifests itself in the sequence of process activations.

For the representation of the interactions between processes, powerful graph models have been developed, such as:

the data flow graph of Karp/Miller /7/ for representing the logical dependencies between processes or process segments,
the requirement graph of Hebalkar /8/ for representing the competition of concurrently running processes for resources that exist only in limited quantities in the system,
the Petri net /9/, /10/, /11/ for describing the control of execution sequences in process systems.

Raubold/Ullrich /12/ derived from these three models a combined model that incorporates the advantages of each and is suitable for representing primarily qualitative interrelationships in the dynamic behavior of the system.

The models cited so far can be recursively refined or coarsened and allow the building blocks of a model of a concrete system to be assigned an interpretation with respect to real system components.

A model that not only offers these advantages but can also be called complete in a certain sense — in that it accounts equally for job-specific and process-interactive aspects — is the formulation of the system as an evaluation net according to Nutt /13/. It is a modification of the Petri net and is to be sketched here for the purpose of illustrating the example of a computer network (Appendix, Figure 2); for

[p. 307]

the exact formalization see /13/). The evaluation net is based on a directed graph with two node types: places and transitions, whereby only nodes of different types may be directly connected. Places can be furnished with tokens, and tokens can be furnished with attributes. Starting from an initial marking of the places, transitions can be made to further markings of the net places in accordance with the rules of the transition declarations, with certain places functioning as decision-makers to resolve conflicts. A transition declaration consists of: the transition schema, which determines the flow of tokens from the input places of the transition to its output places; the time duration of the transition (constant or function); and the transition procedure, which governs the flow of tokens and is responsible for attribute modification. The firing of the transition can be decomposed into 4 phases:

The places of the transition correspond — up to a possible peripheral decision place — to the transition schema (execute the decision procedure).
All places of a transition correspond to the transition schema.
The firing of the transition is in execution (during this active phase the marking remains unchanged).
The transition has fired; the transition procedure is executed and the markings are changed in accordance with the schema.

The sojourn time of a token in a place consists of the time that has elapsed from the placing of the token in the place until the beginning of the active phase of the transition, plus the transition time — thus in total a waiting time plus a service time.

[p. 308]

If places are interpreted as states of jobs or functional units, and the placing of tokens as the beginning or end of the corresponding states, then the sequence of markings reflects on the one hand the flow of jobs through the system and on the other hand the temporal interactions of the processes. The sojourn of tokens in the places provides the desired information about performance measures.

3. Model Synthesis

Model synthesis, whose task is the transformation of the model obtained during system analysis into a functional simulation model taking into account the given simulation objectives, involves among other problems that of determining the appropriate modeling depth — i.e., determining the type and number of parameters, variables, and performance measures used in the model, and the degree of detail of their mutual relationships. The modeling depth, which ideally should be governed solely by the required simulation objectives, can be substantially influenced by:

given cost and time constraints for the experiments,
the capabilities of available tools such as statistical test procedures, simulation languages, or the computer on which the experiments are carried out,
the requirements on the flexibility of the model with respect to structural refinements or coarsenings,
the possibility of using established knowledge about qualitative and quantitative interrelationships of system or model components and performance measures,
the properties of the stochastic processes occurring in the model.

[p. 309]

In order to be able to respond sensibly to such influences, it is advisable to construct models using modular building blocks that can be interpreted with respect to real system components and can be described both by analytical models and by simulation models of varying levels of abstraction. This is to be illustrated using the examples of the communication system and the computer system, since these can well play the role of elementary building blocks in a complex system such as a computer network.

Extensive investigations by Kleinrock /14/ for message-switching communication systems show that such systems can be represented in the model by analytical models, e.g., by a functional description of the sojourn time of a message as a function of origin and destination, message size, and a few parameters characteristic of the communication system, such as capacity or the division of the message into transmission units.

With respect to analytical models for computer systems, the state of the art is unfortunately not yet as advanced. Although a great many usable models exist for partial areas (see /15/, /16/, /17/) — such as models for processor traffic, storage traffic, and traffic between different types of functional units such as processor–periphery or processor–main memory — complete analytical models for the general case are entirely lacking and can only be derived for very special conditions that are rarely satisfied in practice, such as the statistical identity of jobs /17/. Possibilities for nevertheless obtaining usable computer models consist, on the one hand, in choosing an appropriate model for the most prominent characteristic of the computer system /17/, and on the other hand in the stepwise development of a computer system model from models for partial areas into a model for the overall system, whereby the model design and the probability distributions used can advantageously be matched to one another /16/.

[p. 310]

4. Concluding Remarks

The completeness of Nutt’s evaluation net in describing the causal dependence or independence of events arising in process interactions under the influence of job specifications identifies this modeling approach as an impressive tool for the construction of system models as well as simulation models. It supports the implementation of simulation models in one of the simulation languages (GPSS, SIMSCRIPT, SIMULA 67) and thereby also facilitates model verification.

[p. 311]

Appendix

The following simple computer network is used to illustrate, in broad outline, system modeling by means of a queuing model (Figure 1) and an evaluation net (Figure 2).

Two computer systems (R₁, R₂) operate under a centrally organized network control system possessing the components: input unit (E), scheduler (S), communication system (K), and output unit (A). The input unit accepts the job and routes it, if the computer system to be used for processing is already specified in the job description, directly to the communication system. Otherwise, the processing location of the job is first determined in the scheduler. The result of the job executed in the computer system is transferred to the output unit via the communication system.

Figure 1 shows the various stages of job processing through the network.

In Figure 2, the system’s behavior is made more precise by representing the competition of the processes “scheduling” and “updating” for a resource-status table, which the scheduler requires for job assignment and which undergoes updating in accordance with state changes in the computer systems. For reasons of clarity, the influence of the communication system has been suppressed.

Interpretation of Places:

Place	Meaning
b₁ (b₁₀)	Job in queue (WS) of input unit (output unit)
b₂ (b₁₁)	Job being processed by input unit (output unit)
b₃	Job in queue (WS) of scheduler
b₄	Job occupies scheduler and scheduler requires access to status table

[p. 312]

Place / Entity	Meaning
b₆ (b₇)	Job being processed by scheduler, and scheduler has access to status table
b₈ (b₉)	Job in queue of computer 1 (computer 2)
b₈ (b₉)	Job being processed by computer 1 (computer 2)
b₁₂	Job has left the network
c₁ (c₁₀)	Input unit (output unit) available
c₂	Scheduler available
c₃	Status table available
c₄	Updating is to be performed (access to status table is required)
c₅	Updating is being performed (status table available for updating)
c₆	Updating completed
c₇	Request for updating of the status table from computer 1 or computer 2
c₈ (c₉)	Computer 1 (computer 2) available

Decision places (transitions):

Decides, based on the job description, whether the job is routed to computer 1, computer 2, or the scheduler.
Decides on the allocation of access to the status table.
Decides whether the job is directed to computer 1 or computer 2.

While places b₂, b₄, b₅, and c₁, c₂, c₃, c₅, c₆, c₁₀ may be occupied by at most one token at a time, the remaining places can be occupied by multiple tokens in accordance with their capacity. For example, multiple tokens at c₈ or c₉ indicate the possibility of passing a corresponding number of jobs simultaneously to the computer for processing; for b₁, b₃, b₆, b₇, b₁₀, the size of the waiting room can thereby be expressed.

[Page 325]

One of the most suitable methods available today for the analysis of autocorrelated time series is spectral analysis, for which an extensive literature exists (see references /4, 5/) and which has been adapted for simulation applications by Fishman and Kiviat /7, 8/. Although its application is rather demanding and a longer familiarization period is required for a thorough understanding, it provides comprehensive information about the autocorrelation and variance of a time series as well as any oscillatory behavior of system quantities; moreover, once it has been applied, the conventional statistical methods based on independence can be used for further data analysis.

As a final method, mention should be made here of the well-known technique of replicated runs: as soon as the simulation model has reached steady state, the run is stopped and repeated with different random numbers. The respective end values (not cumulative values) are then used to estimate the mean.

Although this method yields independent sample values, it is extremely costly due to the transient period contained in every run, and is therefore recommended only for studies of non-stationary systems and of the transient phase itself. Furthermore, unlike spectral analysis, this method yields only limited information about the temporal behavior of the process.

As a consequence of these considerations, the spectral-analysis method was selected, since it best corresponds to the queuing model with its complexity on one hand and the comprehensive information potential of spectral analysis on the other. For any investigations of non-stationary systems, the method of replicated runs will be employed.

The problems touched upon here do not yet exhaust the scope of questions belonging to experiment design.

[Page 326]

For other problem areas, such as factorial design or variance-reduction techniques, reference is made to the literature /1, 2, 4, 5/. For the present model, however, the problems described above are decisive, especially since the application of variance-reduction methods to a complex queuing system is difficult and their benefit is, by comparison, highly questionable (see also /2/, p. 495).

5. Validation of the Simulation Model

Validation, although placed last within the context of both contributions, must in principle be carried out during each of the phases named in the titles of the papers. However, due to the lack of feasibility and the lower effort involved, it is carried out only after the model has been implemented, at which point it consists of two components:

On one hand, it must be verified that the simulation model behaves as the implementer intends; on the other hand, the validity of the mapping from the real system must be confirmed (a distinction frequently expressed in the literature — see, e.g., /9/ — as the difference between verification and validation).

The former includes, above all, in addition to a confirmation of the program structure by means of a hypothetical trace, the application of the methods mentioned in the two preceding sections — namely, verification of stationarity, transient behavior, and statistical data-evaluation procedures.

Immediately following, or in parallel with, verification comes the validation phase. Since the model refers to a system that exists in reality only in special cases, this step proves to be extremely difficult, especially given that validation in general remains a barely solved problem — one that even admits philosophical considerations (see /5/).

[Page 327]

The position taken here is that a model is not validated until its statements have proven themselves in practice, i.e., against the real system. The aim is therefore to validate the statements of the model as fully as possible. The procedure is as follows:

Comparison of sub-components of the model (computer system, communication system) with existing systems, with mathematical models, and with other simulation studies.
Comparison of the overall model with mathematical models under simplified model structures.

For carrying out these comparisons, spectral analysis again presents itself as one of the most suitable and informationally comprehensive methods (see also /9/).

6. Closing Remarks

In summary, it can be stated that for computer-assisted simulation in the area of system analysis and model synthesis, as well as at the language level, a large number of suitable methods exist. However, with respect to experiment design and validation, although statistics provides some approaches for simulation applications, these are in practice little tested and thus simulation still represents a highly experience-oriented tool for the practitioner.

[Page 328]

References

/1/ Bendat, J. S. and Piersol, A. G.: Measurement and Analysis of Random Data. Wiley, 1966.

/2/ Mihram, G. A.: Simulation: Statistical Foundations and Methodology. Academic Press, 1972.

/3/ Gordon, G.: System Simulation. Prentice Hall, 1969.

/4/ Naylor, T. H. (ed.): The Design of Computer Simulation Experiments. Duke University Press, Durham, 1969.

/5/ Naylor, T. H.: Computer Simulation Experiments with Models of Economic Systems. Wiley, 1971.

/6/ Conway, R. W.: Some Tactical Problems in Digital Simulation. Management Science, Vol. 10, No. 1, October 1963.

/7/ Fishman, G. S. and Kiviat, P. J.: The Analysis of Simulation-Generated Time Series. Management Science, Vol. 13, No. 7, March 1967.

/8/ Fishman, G. S.: Problems in the Statistical Analysis of Simulation Experiments: The Comparison of Means and the Length of Sample Records. Communication of the ACM, Vol. 10, No. 2, February 1967.

[Page 329]

/9/ Fishman, G. S. and Kiviat, P. J.: The Statistics of Discrete-Event Simulation. Simulation, April 1968.

/10/ Mechanic, H. and McKay, W.: Confidence Intervals for Averages of Dependent Data in Simulations II. Technical Report No. ASSD 17-202, IBM, Yorktown Heights, N.Y., 1966.

/11/ Diananda, P. H.: Some Probability Limit Theorems with Statistical Applications. Proc. Camb. Phil. Soc., 1953, 239–246.

/12/ Kubosch, S.: The Structures of the NCC SIMULA Compilers and Bench-Mark Comparisons with Other Major Languages. 2nd GI Annual Conference, 1972.

[Page 330]

Appendix — Requirements for a Simulation Language

The table below compares GPSS V (G), SIMSCRIPT II (S II), and SIMULA 67 (S 67) across several criteria. To provide a rough assessment, the ranking A better than B better than C was introduced.*

Requirement	Notes	GPSS V (G)	SIMSCRIPT II (S II)	SIMULA 67 (S 67)
1. Construction and linking of data structures	In G very specialized; in terms of capability S II and S 67 are equal, but in S 67 simpler and clearer than in S II due to the CLASS concept.	C	B	A
2. Management of simulation time	In G unclear and computationally expensive; in S II and S 67 similar concept.	B	A	A
3. Generation of random numbers and distributions	Distributions in GPSS implementable only “by hand”; S II offers more system functions than S 67.	C	B	[S 67 implied intermediate]
4. Data-analysis functions and data-output routines	In G rigidly fixed but extensive; in S II comprehensive support available, while S 67 provides only a few basic functions.	B	C	[ranked below S II]
5. Data-input routines, initialization, and restart	Similar to criterion 4.	B	C	[ranked below S II]
6. Error-diagnosis and test routines	Not present in S 67; S II and G use a similar concept.	A	B	[absent]

*) The entries “A”, “B”, “C” in the original table denote relative ranking within each row; the exact cell values for SIMULA 67 in rows 3–6 were partially cut off in the source but follow from the accompanying commentary.

Note: Pages 313–324 (preceding this range) contain the earlier sections of two papers on modeling computer networks with Petri nets / evaluation nets and on simulation-model experiment design and validation. Pages 325–330 are the final portion of the second paper (“Simulation Model of a Computer Network System: Experiment Design and Validation” by F. Schumacher), consisting of the concluding discussion of autocorrelation-handling methods, the validation section, closing remarks, the reference list, and the appendix comparison table of simulation languages (GPSS V, SIMSCRIPT II, SIMULA 67). Pages 331–342 of the requested range were not present in the extracted text layer and likely consist of figures, blank pages, or the start of a new document section not captured by the text extraction.

[Pages 331–342: no text-layer content extracted — these pages are either figures only, blank, or outside the text-bearing portion of this document section.]

Requirements for a Simulation Language — Continued (doc p. 331)

Criterion	GPSS V (G)	SIMSCRIPT II (S11)	SIMULA 67 (S67)
7. Model-concept strength and breadth of application	G designed for job-shop problems	S67, owing to its CLASS concept, stronger and more flexible than S11; breadth of application nevertheless equal	—
Rating	C	IA	—
8. Learnability	G probably easiest for beginners	—	S67 difficult to learn
Rating	A	—	IC
9. Modelling and programming effort	G rigid and therefore difficult to handle for larger applications, but easy to code	S11 more extensive than S67	—
Rating	C	IB	IA
10. Compile-time and run-time efficiency	According to a SIMULA implementor /12/:	—	—
Rating	C	—	IA
11. System reliability and manufacturer support	S11 and S67 not supported by any computer manufacturer; for S67 a committee exists in Oslo, for S11 Simulations Associates, Inc.; for an IBM 360/370 user:	—	—
Rating	A	IB	—
12. Documentation, examples	S11 and S67 syntax described in BNF-like form; regarding examples all three are equal	—	—
Rating	B	—	IA

On the Validation of Discrete Simulation Models (doc p. 332)

Heinz Beilner Institut für Informatik, Universität Stuttgart

Paper presented at the workshop “Methodology of Computer-Aided Simulation,” Karlsruhe, 10–11 May 1973

Abstract

The paper discusses the principal problems arising in connection with the question of the trustworthiness of simulation models and their results. Validation, understood as a phase in the development history of a simulator, is set apart from a preceding calibration phase and a subsequent experimentation phase. The essential attitudes toward the problem of validation are discussed, and guidance is given on how this problem was approached in a number of concrete simulation projects.

1. Introduction (doc p. 333)

Simulation models have developed over the past 15 years into a recognized tool for the planning, improvement, and performance assessment of complex systems. This development was accompanied by frequent warnings addressed to model builders never to forget that the usefulness of their simulation models stands or falls with their ability to provide realistic insights into the functional behavior of the real systems being modeled. This goal cannot be achieved in any case by the mere construction of a simulator. Rather, additional efforts must be made to satisfy oneself to a sufficient degree of the trustworthiness of the statements produced by the simulator. Only then can the right be derived, where applicable, to use the results of simulator experiments (in lieu of the results of corresponding experiments in the real world) as the basis for decisions concerning the real systems.

How skeptical one should be toward models that have not been subjected to sufficient testing of their trustworthiness is clearly (in part rather drastically) demonstrated in the literature; here only 3 quotations: Ernst<5>: “Can our models be trusted, or are they involved exercises in self-deception?” Fishman/Kiviat<6>: “Large scale models that are not amenable to validation often lead to perplexing, if not misleading, results.” Schrank/Holt<15>: Something must be done “to prevent the construction of models from being exercises in science fiction.”

Encouragingly, an increased interest in the validation of simulation models has been noted in recent times. Even though a certain carelessness on the part of a number of model builders is still unmistakable, it encounters vigorous opposition (see, for example, Blackmore’s<2> extremely critical paper at the 1972 SCSC, which was devoted exclusively to the deficiencies in validation observed in connection with several papers at the 1971 SCSC). Even more positively, it is worth noting that in recent times a whole series of relevant publications have extensively addressed the methodological difficulties of validation together with corresponding proposed solutions (see Schrank/Holt<15>, Naylor/Finger<12>, v. Horn<7>, Nolan<14>); the forthcoming 1973 SCSC has even declared “validation” one of its central themes.

The present paper attempts to discuss some fundamental questions connected with the validation of simulation models, and to give guidance on the manner in which these questions have been approached in various concrete simulation projects. The validity of the results of simulation models will stand at the center of interest — a positivist standpoint in philosophical terms. This is not to say that the confirmation of the hypotheses and assumptions on which the model rests is regarded as inessential (cf. also Naylor/Finger<12>); rather, such confirmation increases the probability of the validity of simulator results. However, confirmation of the basic assumptions alone is not sufficient to justify the use of a simulator. The use of a simulator, the transfer of simulator statements to the real world, can ultimately be justified only by the credibility of the results of the simulator.

2. Validation — A Development Phase and its Delimitation (doc p. 334)

Simulator and the system to be simulated are not identical. It is therefore not to be expected that they behave identically. A realistic assessment of the behavioral differences between model and real world accordingly forms the basis of every attempt to build any kind of confidence in the results of a model.

Furthermore, such confidence will surely be the greater the smaller the behavioral differences are. Reducing the behavioral differences between reality and model on the one hand, and assessing the behavioral differences in the finished model on the other, are at first glance very similar tasks. As will be shown in the following, it is nonetheless necessary to separate them clearly in the course of developing a simulator and to treat them in two distinct development phases:

a calibration phase, which aims at a reduction of the behavioral differences between reality and model and, in pursuit of this goal, modifies the simulator in an appropriate manner;
a validation phase, the goal of which is an estimation of the behavioral differences between reality and model as they are to be expected in the course of the actual use of the model, i.e., during the subsequent experimentation phase, and in the course of which the simulator is not modified.

In both phases one is confronted with the not inconsiderable problem of how behavioral differences between the real world and the model world can be measured. This common problem must not blur the dividing line between calibration and validation: in the calibration phase the aim is to find a version of the model that approximates the behavior of the real system as closely as possible for a specific set of selected system situations (the availability of corresponding comparative data will be assumed for the moment). In other words, the behavior of the model is adapted to the behavior of the real world as far as possible, but necessarily for a limited set of system situations that covers only a very restricted part of the large set of possible system situations. Now it is precisely the goal of every experiment with the model to predict the behavior of the system in new situations deviating from the calibration situations.

(doc p. 335)

There is no reason to assume that behavioral similarity for a limited set of situations (e.g., calibration situations) automatically transfers to other points in the situation space (e.g., experimental situations). Moreover, in every calibration effort there is a danger of “overfitting” the model, i.e., of incorporating specific peculiarities of the calibration situations into the model during its modification. For these reasons the calibration phase alone cannot provide sufficient statements about how the behavioral differences between reality and model will turn out for situations outside the calibration range. Validation — i.e., estimation of behavioral differences for the experimentation phase — is the task of an additional development phase that must follow every calibration process — indeed, every change to the simulator — and in the course of which the behavioral differences between model and reality must be examined for additional, independent, hitherto unconsidered situations.

Certainly the validation phase can uncover inadequacies of the simulator that were previously unknown. This may necessitate further modifications to the simulator, which in turn may even give rise to a new calibration phase. Impulses of this kind can also arise from the experimentation phase. It would be quite exceptional if, in the course of developing a simulator, one did not already know at any given moment what the next simulator improvements should look like with regard to a better representation of reality. Calibration, validation, and experimentation will alternate cyclically — especially during extended use of a simulator — which makes it all the more necessary always to be conscious of the different goals of these 3 development phases, and not to blur these differences and thereby run the risk of drawing questionable conclusions.

3. On Determining the Behavioral Differences Between the Real World and the Model World (doc p. 335–336)

As already indicated, both calibration and validation proceed from the assumption that the behavioral differences between the real world and the simulation world can be measured in some manner — which is trivially possible only when sufficient knowledge of the behavior of the real world exists for such a comparison. The state of knowledge about the behavior of the real system can vary greatly depending on the particular project. There are cases with comprehensive knowledge, for example when the simulation project aims at improving the performance of a system that has already been in operation for some time and for whose behavior data have been regularly recorded. The knowledge of the behavior of the real system may, however, be considerably less, down to cases where virtually nothing is known about the actual behavior of the system to be simulated, as for example in the planning of a completely novel system.

The problem of obtaining data describing a system’s behavior with which the simulator’s behavior could be compared has been approached in essentially three different ways:

Comparison with the behavior of an existing system, if possible, appears by far to offer the best possibilities. In this approach, the driving input for the simulator is the driving input of the corresponding real system (or its abstraction in the form of an appropriate recording of the driving real input), and the simulator output is compared with the corresponding output of the real system. The terms input and output may appear in various meanings depending on the concrete project. Input may, for example, characterize the workload in job-shop-type systems, but also the sequence of values of strategy and decision variables in economic systems. The term output is to be interpreted correspondingly. In every case, input designates those exogenous variables/events that “drive” both system and model, output those endogenous variables/events that describe the “response” of system and model.

This approach has been successfully employed, e.g., by Boughton/Naylor<4>, who in the course of a simulation of the monetary sector of the USA used a 7-year record of actual system behavior; Beilner/Waldbaum<1>,<16> and Noe/Nutt<13>, who in the course of computer-system simulations drive their simulators with recordings of real workloads (traces) and are thereby able to make detailed comparisons between the behavior of real computing systems and that of the simulators.
Comparison of simulator behavior with the behavior of certain mathematical models that admit analytical solutions is another possible approach. This path was taken where a comparison with real system behavior was not feasible (either because no corresponding real system existed, or because no records of real system behavior were accessible); in some cases the method was also used additionally to comparisons with real system behavior. Since mathematical models of complex systems are frequently amenable to analytical solution only when the model structure and operating conditions for the model are subjected to considerable, sometimes even unrealistic, restrictions — and since this very fact is the actual reason why simulation models in many cases are the only possible realistic models of certain complex systems — the method indicated here may appear in some ways contradictory and requires clarification: the method proceeds from the assumption that the simulation model of a given system must work satisfactorily not only under realistic operating assumptions but also under the restrictive assumptions that make a corresponding mathematical model analytically solvable. The simulator is brought into direct relationship with the analytically solvable model by normally straightforward modifications of structure and input; a comparison of the two models thereby becomes a meaningful task.

(doc p. 337)

Reports on the use of this method are found in the literature, e.g., by Blatny/Clark/Rourke<3>, who when simulating a time-sharing system compare the behavior of their simulator under special conditions with several analytically derived behavioral patterns; Naylor<11>, who when simulating a business operation compares the behavior of his simulator in special cases with the behavior of an analytically tractable model.

Finally, there are the apparently hopeless cases where neither a real system nor an analytically solvable model exists with whose behavior the simulator behavior could be compared. A certain degree of assistance can here be provided by any similar systems that may exist, for which valid simulators are available. Ernst<5> mentions such a “reference to a past clean validation against reality of the model type which the conceptual modeller is using,” and Nolan<14> reports on “validating, in a relative sense, a proposed system against an existing one” in the course of the simulation of an aircraft maintenance system.

An approach indicated by Fishman/Kiviat<6> may possibly offer a more general solution to the problem. Without a more precise exposition of the approach, it appears to suggest there a bootstrapping-like procedure in which one begins with simulation models of simple systems whose validity can be confirmed (which must of course be similar in some sense to the system under investigation) and reaches the final model in possibly several intermediate steps; each step creates a progressively more complex model and confirms its validity with respect to the model of the preceding step. Such a procedure is practiced, at least in approximation, by Marte, Kuespert, and Walke<9>,<17>, who in the course of modeling a time-sharing system repeatedly alternate between the use of analytical and simulation models.

(doc p. 338)

Besides the question of what the simulator behavior can meaningfully be compared with, a further considerable problem lies in the question of how such a comparison is to be carried out (for simplicity, the system with whose behavior the simulator behavior is compared will henceforth be called the “real” system; this is not to say that, as shown in the preceding sections, other systems cannot take its place). The question of “how to compare?” encompasses in reality two distinct problem areas, namely on the one hand which data characterize a system’s behavior and should therefore serve as the basis for behavioral comparisons, and on the other hand by what methods the comparison can be carried out.

This is not the place to go into details — competent publications are readily accessible (cf. Naylor/Finger<12>). It will suffice to state that for neither of the two problems is there “the” answer, that the answers depend rather on the problem at hand. Different measures and methods will be employed for event-dominated microscopic studies (where, for example, the timing of certain events may be of interest) as distinct from flow-dominated macroscopic studies (where, for example, the value sequences of certain central variables might need to be considered). Systems for which stationary behavior can be assumed will be treated differently from those for which this assumption is not justified (such as batch computing systems).

Two more general points, however, should be briefly touched upon here. The first concerns methods for comparing characteristic data. This is where statistics comes into play. Now every statistical test has its preconditions and should only be applied after conscientious verification of whether these preconditions are met. This is fairly obvious for parametric tests (the tiresome “normality”) — it is not so obvious for so-called nonparametric tests (yet they too have preconditions such as “symmetric distribution” or at least “random sample”) or for methods such as spectral analysis (which assumes “weak stationarity”). That much is sinned against here is an open secret — in many cases verification of test preconditions is simply not feasible — and it is certainly worth the effort to include in the considerations, at least additionally to formal tests, an alternative approach sometimes referred to as “Turing’s test” (cf. v. Horn<7>, Hutchinson<8>), an approach that makes the human being the decision-maker as to how well the real world and the simulation world agree in their behavior.

The second point to be discussed here relates to the types of data that are regarded as characteristic of the behavior of the real world and the simulator, and that should therefore serve as the basis for a behavioral comparison. These data should not be viewed in isolation but always in relation to the desired capabilities of a simulator, among which its predictive power is probably the most valuable.

(doc p. 339)

Now in every simulation project there are certain specific variables (or functions of such variables) whose future development is of particular and central interest. Often these variables/functions represent, for example, measures of the performance capability of the systems. From this viewpoint it is only natural to require behavioral similarity between real system and simulator precisely with respect to these central variables/functions. To be sure, that kind of behavioral similarity increases confidence in the simulation model — but obviously (especially in trade-off cases) the main weight of the behavioral comparison should lie on the similarity of the central variables/functions.

Viewed thus, it does not pay to invest too much work in developing the “correct” measures for behavioral differences between real systems and simulation models — the determination of central quality measures is in most cases a management question pertaining to the system being studied, a political question, and thus lies outside the sphere of work of the model builder.

4. Validation — Fundamental Approaches (doc p. 339–340)

Ernst<5>: “Validation is the determination of the domain of situations for which the model performs within a given accuracy, with an established calibration.” v. Horn<7>: “Validation is the act of increasing to an acceptable level the confidence that an inference about a simulated process is correct for the actual process.” These excellent yet obviously differing definitions illuminate the two different standpoints from which the validity problem can be viewed.

Ernst refers to the formal aspect of validation by introducing the notion of a situation space, divided into two disjoint subspaces, one of which encompasses all those situations in which the simulator meets the given accuracy requirements (the simulator delivers “valid” results), while the other includes all those situations for which the simulator results are considered invalid. The calibration situations are to be imagined somewhere within the validity subspace. Validation would then consist of checking additional situations to determine whether they are to be counted among the valid situations or not. To make the definition truly workable, however, an extrapolation (or interpolation) method would have to be developed that would permit inference from the validity of the simulator in tested situations to its validity in previously untested situations. It is conceivable that such methods could be developed with respect to numerical system parameters. It is difficult, however, to imagine what a general such method would look like, applicable also, for example, to a case where different decision strategies are to be assessed by means of a simulator and statements about the validity of this assessment are required.

(doc p. 340)

An essential implication of Ernst’s definition should, however, in any case be kept in mind: it is the finding that the validity of a simulator is a merely relative matter. A simulator is not either valid or invalid; rather, it delivers valid results for a certain set of situations, invalid results for the remaining situations — and this in relation to prescribed accuracy requirements.

v. Horn’s definition does not insist on a formal proof of simulator validity as such — it also admits a (subjective) confidence that the simulator’s statements will be valid in certain situations. To be sure, even this confidence must be grounded in the formal verification of the validity of simulator results in situations outside the calibration range. However, the concept of a continuously developing subjective confidence in the results of a simulator that has been in long-term use can help to escape the awkward situation characterized by the following two attitudes:

“The validity of a simulator can be regarded as demonstrated only when recommendations from the simulation model (derived from experiments with the simulator) have been implemented in the real world and a verification of the probable effects of the system changes predicted by the simulator is consistent with the effects that actually occurred.”

“It is too dangerous (costly, etc.) to adopt simulator recommendations into the real system before the validity of the simulator has been demonstrated.”

In any case, confidence in the results of a simulator can only be built up if the validity of the results for situations outside the calibration range has been demonstrated, i.e., only by means of separate simulator runs expressly for the purpose of validation. Validation test situations can certainly be designed, the simulator then used to predict the behavior of the real system for these situations, the real system subsequently modified accordingly, and the behavior of the real system compared with the predictions of the simulator, thereby determining whether the predictions were valid. Such an approach to validation will, however, frequently encounter resistance (as before: danger, costs, etc.) — a validation without direct involvement of the real system would certainly be more welcome.

Historical validation is one such way of conducting validity tests without involving the real system. It presupposes that records of the system’s past behavior are available with which the behavior of the simulator (possibly modified accordingly) can be compared. The method of historical

(doc p. 341)

validation can be employed to test the validity with respect to both the driving input and the system structure:

Input validity can be tested by operating the simulator with inputs that were not used during the calibration phase and subsequently comparing the simulator’s behavior with the corresponding behavior of the real world, in order to determine whether these behaviors are similar enough, i.e., whether the results of the simulator are valid for new input situations.
Structural validity can be tested if records are available of the behavior of the real system for periods during which the real system differed structurally from the version considered in the calibration phase. Such periods may be characterized, for example, by the presence of different system components (quantity and/or type), but also by the existence of different operating strategies, etc. The structure of the simulator is in these cases to be modified appropriately (i.e., with respect to the structural differences), and the simulator’s behavior compared with records of the behavior of the real world in these structurally different situations.

Historical simulation is an extremely valuable tool that should be employed for purposes of validation wherever possible. In order not to forfeit this favorable tool, care should be taken not to consume all records of historical system behavior already in the calibration phase (since this phase too can make advantageous use of historical system behavior), but to set aside a sufficient quantity of these records for purposes of validation.

5. Concluding Remarks (doc p. 342)

In this paper an attempt was made to illuminate some of the difficult questions that arise in the course of building confidence in the results of simulation models. Validation as a phase in the course of the development of a simulator was set apart from a calibration phase preceding validation and an experimentation phase following validation. Various fundamental attitudes toward the problems of validation were discussed, and guidance was given on how these problems were approached in concrete simulation projects. The state of the methodology in this field is far from satisfactory. However, if one notes the degree to which the necessity of validation has entered general awareness and considers the manifold efforts directed at this problem, then one can look to the future with some hope for early progress.

References

<1> Beilner, H. and Waldbaum, G.: Statistical Methodology for Calibrating a Trace-Driven Simulator of a Batch Computer System. In Freiberger, W. (ed.): Statistical Computer Performance Evaluation, Academic Press, 1972.

<2> Blackmore, W. R.: Pitfalls, Pratfalls and Pleas in Monte Carlo Simulation. Proc. of the 1972 Summer Computer Simulation Conference, San Diego.

<3> Blatny, J., Clark, S. R. and Rourke, T. A.: On the Optimization of Performance of Time-Sharing Systems by Simulation. CACM 15 (1972), nr. 6.

<4> Boughton, J. M. and Naylor, T. H.: A Model of the United States Monetary Sector. Chapter 15 in <10>.

<5> Ernst, H. A.: Problems in Computing Systems Performance Modelling: Characterization, Calibration and Validation. IBM Research Report RC 3319, 1971.

<6> Fishman, G. S. and Kiviat, P. J.: Digital Computer Simulation: Statistical Considerations. RAND Memorandum RM-5387-PR, 1967.

<7> v. Horn, R. L.: Validation of Simulation Results. Management Science, 17 (1971), nr. 5.

<8> Hutchinson, G. K.: The Use of Simulation in the Design of a Multi Computer Operating System. Technical Report, University of Wisconsin, Milwaukee.

<9> Kuespert, H. J. and Marte, G.: Optimale Rechenzeitzuteilung bei einem Teilnehmerrechensystem mit jeweils einer Aufgabe im Arbeitsspeicher. Elektronische Rechenanlagen 12 (1970), nr. 3.

<10> Naylor, T. H. (ed.): Computer Simulation Experiments with Models of Economic Systems. J. Wiley & Sons, 1971.

<11> Naylor, T. H.: Analysis of Variance. Chapter 7 in <10>.

<12> Naylor, T. H. and Finger, J. M.: Validation. Chapter 5 in <10>.

<13> Noe, J. D. and Nutt, G. J.: Validation of a Trace-Driven CDC 6400 Simulation. Proc. of the SJCC, 1972.

<14> Nolan, R. L.: Verification/Validation of Computer Simulation Models. Proc. of the 1972 Summer Computer Simulation Conference, San Diego.

<15> Schrank, W. and Holt, Ch.: Critique of Verification of Computer Simulation Models. Management Science 14 (1967), nr. 2.

(doc p. 343)

<16> Waldbaum, G. and Beilner, H.: SOUL — A Simulation of OS Under LASP. Proc. of the 1972 Summer Computer Simulation Conference, San Diego.

<17> Walke, B.: Die mittlere Verweilzeit in Teilnehmerrechensystemen bei optimaler Rechenzeit-, Arbeitsspeicher- und Transportkanalzuteilung. Nachrichtentechnische Fachberichte, vol. 44 (1972), VDE Verlag, Berlin.

Sample Size in Monte Carlo Simulation (doc p. 344)

M. Helm

Introduction

While a large number of excellent languages exists in the field of Monte Carlo simulation, one encounters in the literature relatively rarely simulation studies that are carried out in a completely correct manner. The reason for this is the absence of program systems that would enable the user to perform a mathematically sound analysis of the input data and of the results obtained through simulation, and that would thus represent a complement to the simulation language itself.

Thus the user of simulation languages sometimes stands completely helpless before these often very subtle problems of mathematical statistics, and the situation may arise in which statements worked out with great effort by simulation are misleading because they were not anchored carefully enough in reality.

A program system will therefore be presented that is initially based on the method of the autoregressive model, well known from the field of time-series analysis and introduced into simulation by G. S. Fishman [1], [2], [3], [4]. It should enable the user to track the development of the accuracy of the relevant model quantities from the screen of a terminal, and thus to run the simulation actively in dialogue with the model until the required accuracy is achieved or a continuation of the run no longer appears worthwhile for economic reasons.

(doc p. 345)

To this end, Section 1 discusses the estimation of tolerance intervals for means. Section 2 addresses the treatment of the transient phase, Section 3 explains the operation of the interactive program, and finally Section 4 provides a critical assessment of the method and draws attention to further points to be investigated.

1. Determination of Sample Size (doc p. 345)

The question addressed in this section is: How long must a simulation run until the accuracy of the mean value of a model variable demanded by the user is achieved?

For this purpose the most important points of the theory will be assembled. A detailed presentation can be found in G. S. Fishman [1].

Let the simulation produce a realization from the ensemble of a stochastic process {X} (for example, let {X_t} be the length of the queue in front of a counter, measured at regular intervals, etc.).

Now let {X_t, t = 0, ±1, ±2, …, ±∞} be covariance-stationary in the sense that:

E[X_t] = μ for all t, (1.1)
Cov(X_t, X_s) = R_{t−s} for all t and s. (1.2)

Here μ is the expected value and R_{t−s} is the autocorrelation function of the process.

(doc p. 346)

In many cases the expected value is of interest, for which an estimate within prescribed tolerance bounds is desired.

This estimate for μ is:

$$\bar{X}N = \frac{1}{N} \sum{t=1}^{N} X_t$$

It can be shown (Bernstein’s theorem) that properties (1.1) and (1.2) ensure that X̄_N for N → ∞ is normally distributed with expected value μ and variance V_N.

Therefore the relationship holds:

$$P!\left(\left|\bar{X}N - \mu\right| \leq z\alpha \sqrt{V_N}\right) = 1 - \alpha \qquad (1.4)$$

where (1 − α) is the confidence level and z_α is the quantile of the N(0,1) normal distribution corresponding to this level.

The problem of determining a tolerance interval for X̄_N is thus reduced to finding an estimate for V_N.

Now for N → ∞:

$$V_N \cdot N = W = \sum_{s=-\infty}^{\infty} R_s \qquad (1.5)$$

The autocorrelation functions for s = 0, ±1, ±2, … are

(doc p. 347)

difficult to estimate from a finite realization of length N. The hypothesis is therefore advanced that the general representation of the process {X_t} as an infinite autoregressive process can be approximated by a finite one, i.e., that the following model holds:

$$X_t = \sum_{s=1}^{p} b_s X_{t-s} + \varepsilon_t \qquad (1.6)$$

Here ε_t is to be white noise, i.e.,

$$E[\varepsilon_t] = 0, \quad E[\varepsilon_t \cdot \varepsilon_s] = \begin{cases} \sigma^2 & t = s \ 0 & t \neq s \end{cases} \qquad (1.7)$$

It can now be shown that for the quantities from (1.5), (1.6), and (1.7) the following relationship holds:

$$W = N \cdot V_N = \frac{\sigma^2}{\left(1 - \sum_{s=1}^{p} b_s\right)^2} \qquad (1.8)$$

Using the method of least squares one can give estimates for the coefficients b_s whose errors diminish as 1/√N. With (1.8) a usable estimate for the variance of the mean V_N has thus been found.

Now (1.5) is substituted into (1.4) and the tolerance interval is measured in units of the expected value. One therefore sets z_α √(W/N) = c · μ, where c represents the percentage accuracy of the mean. This yields for the required sample size the estimate

$$N \approx \frac{W}{(c \cdot \mu)^2} \cdot z_\alpha^2 \qquad (1.9)$$

2. The Transient Phase (doc p. 348)

In no simulation experiment is (1.1) satisfied, since one always starts from an arbitrarily chosen initial state X_0 and the stationary state is reached (if at all) only in the limit t → ∞. This fact can be expressed by the following relationship:

$$\lim_{t \to \infty} E[X_t \mid X_0] = \mu \qquad (2.1)$$

where E[X_t | X_0] is the conditional expected value.

In order to eliminate the influence of the initial state X_0, one attempts to satisfy (2.1) approximately by discarding the first K measured values and using as the estimate of the expected value:

$$\bar{X}{N,K} = \frac{1}{N-K} \sum{t=K+1}^{N} X_t \qquad (2.2)$$

The problem now lies in determining a K such that on the one hand the bias of the mean caused by the arbitrary initial state remains small, and on the other hand the loss of measured values — which leads to an increase in the variance of X̄_{N,K} — does not become too large (see also [2]).

In [1] the following heuristic proposal is made for K:

Two processes are considered: an independent process (cf. (1.1)) with variance σ², and…

Non-Linear Parameter Estimation

[page 361]

The adaptation problem constitutes a problem of non-linear parameter estimation, for the solution of which two methods are principally employed. The first method goes back to Gauss.

The model variables Y(b) are expanded in a Taylor series with respect to the parameters b_i:

Y(t_i, b + δ) = Y_0(t_i, b) + Σ_i [∂Y/∂b_i]_(0) · δ_i = Y_0 + P·δ     (5.1)

where δ represents a small correction of the parameter vector b, and P is the gradient matrix (∂Y/∂b_i) of the model function.

The Gaussian error function

F(δ) = Σ_i [Y*(t_i) - Y(t_i)]²     (5.2)

with the measured-value vector Y*(t_i) and the model variables Y(t_i) is used as the criterion for fitting the model. After substituting the linearized model function Y(t_i, b+δ), Eq. (5.2) becomes a quadratic function of the parameter correction δ. The optimal model parameters are found when, by varying δ, the error function F(δ) reaches its absolute minimum. The conditions for δ_min are well known:

P^T · P · δ_min = P^T · [Y* - Y_0]     (5.3)

and constitute a linear system of equations for determining the parameter corrections δ.

The second method is known as the gradient method or “steepest descent method.” Here the parameter-correction vector δ is obtained by forming the negative gradient of the error function F(b):

[page 362]

In other words, one seeks to reach the minimum of the error function in the direction of steepest descent.

The Gaussian method has the advantage of fast convergence in well-behaved cases. However, the linearization required in Eq. (5.1) very easily leads to unstable behavior for functions that are not everywhere convex. The gradient method, by contrast, initially converges quite well in all cases. As the sought minimum is approached, however, the rate of convergence becomes intolerably slow.

W. Marquardt developed a combination of both methods that unites all of the advantages and largely avoids the disadvantages [4]. The procedure is called the “maximum neighbourhood method” and is based on imposing a constraint on the region for δ when searching for the minimum of F(δ). This side condition yields the determining equation for δ_min:

(P^T·P + α·I) · δ_min = P^T · [Y* - Y_0]     (5.5)

The scalar factor α determines the size of the region ‖δ‖ (constraint region for parameter corrections).

A comparison of Eq. (5.3) with Eq. (5.5) shows that for large values of α the Gaussian method is approximated. For small values of α, Eq. (5.5) approaches an expression proportional to Eq. (5.4), i.e. the gradient method is approximated. From this the strategy for choosing the factor α is derived: at the start of the fitting procedure a small value for α is chosen. The procedure thereby starts with the gradient method and converges even with unfavorable initial parameter values.

[page 363]

Toward the end of the fitting process, α is chosen very large. In the vicinity of the minimum, F(b) is certainly convex, and the Gaussian method with its fast convergence can be applied without risk.

6. The Adaptive Model ESADAP

The Marquardt algorithm was used to construct the adaptive model. Figure 5 shows the structure of the digital program ESADAP. The main program MAIN controls the I/O operations. It initiates the transfer of measured values from tape to disk storage and controls the output of the optimal model parameters as well as the simulation results. The main program also starts and terminates the actual simulation run through direct communication with the base model ESIDYN.

The subroutine REGR controls and monitors the process of fitting the model variables to the measured values. The most important task of REGR is to supervise the search for min F(b) in accordance with the strategy of the “maximum neighbourhood method” described above. This includes the selection of a suitable factor α, which necessitates repeated computation of the error function F(b). Furthermore, REGR calculates the correction vectors δ_min by solving the system of equations (5.5).

The calculation of the matrix P required for this is carried out in the subroutine FCODE. The components of P are the derivatives (∂Y/∂b_i) of the model function with respect to the current parameter values — in the present case, the gradients (∂φ/∂b_i), (∂θ/∂b_i), and (∂ψ/∂b_i). These differentials are approximated in FCODE by finite difference expressions of the form [φ(b_i + Δb_i) − φ(b_i)] / Δb_i.

The values of the model function φ(t_i, b_i), θ(t_i, b_i), ψ(t_i, b_i)

[page 364: figure only — block diagram of the adaptive model ESADAP]

[page 365]

at a prescribed time t_i and with prescribed parameters b_i are obtained by calling the subroutine ESIDYN. This program section encompasses the base model described in Section 4. The subroutine GJR serves to perform the repeated matrix inversions, which are carried out by the Gauss–Jordan–Rutishauser method.

The program runs in two stages. It begins with the fitting process of the base model, i.e. the search for the optimal model parameters by REGR. The search is complete when the error function F(b) falls below a prescribed minimum value ε. The optimal model parameters found are then returned to the main program. After the fitting process, the main program starts the simulation run directly. For this purpose, the base model is supplied with the initial values of the attitude angles and their derivatives, the optimal parameters, and the simulation duration. After the simulation is complete, the main program again arranges the output of the computed attitude angles to a listing or tape. The complete model ESADAP is programmed for double word length and requires, together with the base model ESIDYN, 160 K of storage space. The computing time required depends primarily on the number of parameters b_i and the number of measured values. As an example, the following figures may be cited: for a set of 300 measurement points, the program required on an IBM 360/65:

Parameters	CPU time
6 parameters	31 min
16 parameters	60 min
25 parameters	101 min

[page 366]

References:

[1] ESRO-I Spacecraft Description, TR-10, ESRO Paris

[2] R. Kammüller, Nonlinear Resonant Roll Motion, AIAA Journal, April 1971

[3] R. Kammüller, Roll Resonance and Roll Control, AIAA Journal, Feb. 1972

[4] D. Marquardt, Algorithm for least-square estimation, J. Soc. Appl. Math., June 1963

[Pages 367–378 fall outside the content extracted from this page range; the PDF text layer for pages 367–378 returned no additional content beyond page 366, indicating those pages consist of figures, blank pages, or the content was not captured by the text layer within this range.]

2. The Simplified Computer Model

In this contribution the discussion is restricted to a computer model with the active resources:

1 processor core RK
1 transport channel TK

and the passive resources:

1 finite main memory ASPABW with ABW program slots, corresponding to the number of processors in the BS3
1 infinite backing store HSP∞

The applicability of the method developed below is not affected by a different configuration of active resources.

The service time t_RK of the processor core (duration of one subtask) has the distribution

P[t_RK ≤ t] = 1 − e^(−μt)

and the service time t_TK of the transport channel (duration of one supplementary transfer) has the distribution

P[t_TK ≤ t] = 1 − e^(−λt)

A set Z of model states is defined:

Z = {E₀, …, E_ABW}

where state E_i means that i slots in the queue in front of the processor core are occupied. The processor core slot itself is counted as part of the queue.

In state E₀ the processor core is idle; in state E_ABW the transport channel is idle. In all states E_i, 1 ≤ i ≤ ABW−1, both the processor core and the transport channel are occupied.

[page 380]

The time axis is divided into intervals by events that change the state of the model, with division points t_K.

Let E be the mapping from time t to the set Z of states. The time intervals Δt(k) = t_{K+1} − t_K are random variables whose distribution depends on the state of the computer model:

At time t_K state E₀ = E(t_K) is reached. The distribution of Δt(K) is then
```
P{Δt(K) ≤ t | E(t_K) = E₀} = 1 − e^(−λt)
```
At time t_K state E_i = E(t_K), 1 ≤ i ≤ ABW−1, is reached. The distribution of Δt(k) is then
```
P{Δt(k) ≤ t | E(t_K) = E_i} = 1 − e^(−(μ+λ)t)
```
At time t_K state E_ABW = E(t_K) is reached. The distribution of Δt(k) is then
```
P{Δt(k) ≤ t | E(t_K) = E_ABW} = 1 − e^(−μt)
```

Because the remaining service time t_rest = t_RK − t₀ has the same distribution as t_RK, preemptions during subtask processing by other subtasks can be permitted without altering the relationships.

The transition probabilities

P_{ij}(K) = P{E(t_{K+1}) = E_j | E(t_K) = E_i}

are now determined.

Suppose the system is in state E₀. Then only the transport channel TK is occupied and, at the next event independently of the step number K, it certainly generates a new subtask; following state E₀, state E₁ occurs with probability 1:

P₀₁ = 1,   independent of K.

Suppose the system is in state E_i, 1 ≤ i < ABW. Processor core RK and transport channel TK are simultaneously occupied. The probability that the processor core or transport channel finishes in the interval (t, t+dt) is μ dt or λ dt respectively. The probability that any event occurs in this interval is (μ + λ) dt. The conditional probability that in this interval, given an event, the processor core completes a subtask (or the transport channel generates one) is μ/(μ+λ) (or λ/(μ+λ)). Therefore, following state E_i, state E_{i−1} (E_{i+1}) occurs with probability μ/(μ+λ) (λ/(μ+λ)):

P_{i,i−1} = μ/(μ+λ),   P_{i,i+1} = λ/(μ+λ),   independent of K.

[page 381]

Suppose the system is in state E_ABW. Then only the processor core is occupied. With probability 1, at the next event a subtask is completed; E_ABW is followed with certainty by E_{ABW−1}:

P_{ABW, ABW−1} = 1,   independent of K.

All other transition probabilities are evidently equal to 0, independently of K.

It is now evident that this constitutes a Markov chain with transition matrix P = (P_{ij}) for all steps K.

[page 382]

$$P = \begin{pmatrix} 0 & 1 & 0 & 0 & \cdots & 0 & 0 & 0 \ m & 0 & n & 0 & \cdots & 0 & 0 & 0 \ 0 & m & 0 & n & \cdots & 0 & 0 & 0 \ & & & & \ddots & & & \ 0 & 0 & 0 & 0 & \cdots & m & 0 & n \ 0 & 0 & 0 & 0 & \cdots & 0 & 1 & 0 \end{pmatrix} \tag{2}$$

where

m = μ/(μ+λ),   n = λ/(μ+λ)

3. The Stationary State of the Computer Model

The Markov process with transition matrix P is periodic with period t = 2. The set of states therefore divides into two disjoint groups G₁, G₂ with the following property:

If after n steps the process is in state E_K ∈ G₁, then after n+1 steps it is certainly in a state E_l ∈ G₂, after n+2 steps certainly in a state E_m ∈ G₁, and so on. It is evident that the even-indexed states can be collected into G₁ and the odd-indexed states into G₂.

The elements of matrix P^n are denoted P_{ij}^(n). P_{ij}^(n) is the probability that the process, starting in state E_i, reaches state E_j after n steps. It is established that all states of the Markov chain are recurrent, i.e. there is no positive integer N < ∞, no matter how large, such that for all n ≥ 0

P_{jj}^(n+N) = 0.

[page 383]

Therefore (see W. FELLER: An Introduction to Probability Theory and its Applications, Vol. I, p. 405):

$$\lim_{n \to \infty} P_{ij}^{(n)} = \begin{cases} U_{E_K} & \text{if } E_K \in G_1 \ 0 & \text{if } E_K \in G_2 \end{cases}$$

where the U_K are the solution of the equation

$$\sum_K U_K \cdot P_{Kj} = U_j \tag{3}$$

normalized by

$$\sum_K U_K = 1 \tag{4}$$

The solution of (3) for ABW = 2, 3 and 4 program slots in main memory gives:

(5) ABW = 2

U₀ = m
U₁ = 1/2
U₂ = n

(6) ABW = 3

U₀ = m² / (m² + n² + 1)
U₁ = m  / (m² + n² + 1)
U₂ = n  / (m² + n² + 1)
U₃ = n² / (m² + n² + 1)

(7) ABW = 4

U₀ = m²         / (m³ + m²n + mn + n² + n³)
U₁ = m²n        / (m³ + m²n + mn + n² + n³)
U₂ = mn         / (m³ + m²n + mn + n² + n³)
U₃ = n²         / (m³ + m²n + mn + n² + n³)
U₄ = n³         / (m³ + m²n + mn + n² + n³)

[page 384]

4. Throughput and Statistical Error

The aim is now to determine how throughput can be calculated from the relative utilization B_RK or B_TK of resources RK or TK respectively. The definition (1) of throughput required that the model be operated under job saturation. Since all segments have the same computation-time and transfer-time behavior, the end or beginning of a segment is an arbitrary boundary.

Instead of segment throughput, the throughput of subtasks can therefore be considered. Segment throughput is obtained from subtask throughput by dividing by the mean number of subtasks per segment.

The subtask throughput is

$$d = \frac{n}{t(n)} \tag{8}$$

where

n = number of subtasks
t(n) = time required to process n subtasks

When n is sufficiently large:

$$\sum_{K=1}^{n} t_{RK}(K) \approx n \cdot E(t_{RK})$$

From this it follows:

$$d = \frac{n}{\displaystyle\sum_{K=1}^{n} t_{RK}(K)} \cdot \frac{\displaystyle\sum_{K=1}^{n} t_{RK}(K)}{t(n)} = \frac{1}{E(t_{RK})} \cdot B_{RK} \tag{9}$$

Since each subtask is followed by a supplementary transfer, n in (8) can also be interpreted as the number of supplementary transfers. Therefore it also holds that

[page 385 — continuation of throughput derivation]

$$d = \frac{1}{E(t_{TK})} \cdot B_{TK} \tag{10}$$

where B_TK denotes the relative utilization of the transport channel.

The relative utilization B_RK of the processor core is

$$B_{RK} = 1 - U_0 \tag{11}$$

because in state E₀ only the transport channel is busy and the processor core is idle.

The relative utilization B_TK of the transport channel is

$$B_{TK} = 1 - U_{ABW} \tag{12}$$

because in state E_ABW only the processor core is busy and the transport channel is idle.

From (9), (10), (11) and (12) the throughput D of segments is then

$$D = d / \bar{r} \tag{13}$$

where r̄ is the mean number of subtasks per segment.

Statistical error of the throughput determined by simulation

The throughput d is estimated from the simulation by (8). One asks for the statistical error of this estimator.

The process of subtask completions can be considered as a renewal process. The inter-renewal times are the intervals between successive subtask completions. Let these intervals be denoted ξ_K. They are not independent, since the duration of an interval depends on which state the system was in.

However, for a stationary Markov chain, the law of large numbers and the central limit theorem apply in the following form (see P. BILLINGSLEY: Statistical Inference for Markov Processes, University of Chicago Press, 1961):

$$\frac{1}{n} \sum_{K=1}^{n} \xi_K \xrightarrow{n \to \infty} E(\xi) \quad \text{almost surely}$$

and

$$\sqrt{n} \left( \frac{1}{n} \sum_{K=1}^{n} \xi_K - E(\xi) \right) \xrightarrow{} N(0, \sigma^2)$$

where σ² is an asymptotic variance that accounts for the correlations between successive intervals.

[page 386]

The asymptotic variance σ² of the interval lengths ξ_K is

$$\sigma^2 = \text{Var}(\xi_1) + 2 \sum_{j=2}^{\infty} \text{Cov}(\xi_1, \xi_j) \tag{14}$$

For the simplified model, σ² can be calculated analytically. The variance Var(ξ₁) and the covariances Cov(ξ₁, ξ_j) are determined from the transition matrix P and the distribution of the interval lengths in each state.

The statistical error ε_d of the throughput estimator d (at a given confidence level) is then

$$\varepsilon_d = z_\alpha \cdot \frac{\sigma}{\sqrt{n} \cdot E(\xi)} \tag{15}$$

where z_α is the quantile of the standard normal distribution corresponding to the chosen confidence level, n is the number of subtasks observed, and E(ξ) is the mean interval length.

The relative statistical error ε_D of the segment throughput D equals the relative error of d, since D = d / r̄ and r̄ is a fixed parameter in the simplified model.

5. Calculations

For the calculation of the statistical error, the following parameters of the simplified model are required:

μ: service rate of the processor core (reciprocal of mean subtask duration)
λ: service rate of the transport channel (reciprocal of mean supplementary transfer duration)
ABW: number of program slots in main memory

The parameter m = μ/(μ+λ) and n = λ/(μ+λ) characterize the ratio of processor core speed to transport channel speed.

[page 387]

Calculations were carried out for various values of the ratio ρ = μ/λ and for ABW = 2, 3, and 4 program slots.

The stationary state probabilities U_i are given by formulas (5), (6), (7). From these the relative utilizations B_RK = 1 − U₀ and B_TK = 1 − U_ABW are computed.

The throughput, expressed in units of μ (the service rate of the processor core), is

$$d \cdot E(t_{RK}) = B_{RK} = 1 - U_0$$

The asymptotic variance σ² of the interval lengths is computed from (14). The individual terms of this series converge geometrically, so the series can be truncated after a finite number of terms with negligible error.

Numerical results for the relative statistical error ε_D as a function of the number of observed segments N (where N = n / r̄) show the following behavior:

The relative error decreases as 1/√N, consistent with the central limit theorem.
For a fixed N, the error is larger when ρ ≈ 1 (processor core speed approximately equal to transport channel speed), i.e., when neither resource dominates and the system alternates frequently between states.
The error is smaller when ρ ≫ 1 or ρ ≪ 1, because in these cases the system spends most of the time in boundary states (E₀ or E_ABW) and the interval lengths are nearly independent.
Increasing ABW (more program slots) increases the correlation between successive intervals and thus increases σ², leading to a larger error for the same N.

[page 388]

Concrete numerical examples for ABW = 2 and several values of ρ are given in Table 1.

Table 1. Relative statistical error ε_D (%) for ABW = 2 as a function of number of observed segments N and utilization ratio ρ = μ/λ.

N \ ρ	0.5	1.0	2.0
100	3.2	5.1	3.2
500	1.4	2.3	1.4
1000	1.0	1.6	1.0
5000	0.45	0.71	0.45
10000	0.32	0.50	0.32

(Values are approximate, based on a 95% confidence interval, i.e., z_α = 1.96.)

The symmetry with respect to ρ = 1 reflects the symmetry of the model: swapping μ and λ (i.e., exchanging the roles of processor core and transport channel) yields the same statistical error by symmetry when ABW = 2.

For ABW = 3 and ABW = 4, the errors are somewhat larger due to the increased correlation structure of the Markov chain.

[page 389]

6. Discussion of Results

The results show that the statistical error of the throughput determined by simulation depends in a transparent way on the model parameters and the simulation run length.

Practical implications for simulation experiments with BS3SIM:

For a prescribed relative statistical error of, say, 1% (at 95% confidence), the required number of segments N can be read off from the results. For the case ρ = 1 and ABW = 2, approximately N = 1000 segments must be processed; for more extreme values of ρ or larger ABW, N requirements differ accordingly.

This analysis enables the experimenter to plan simulation runs in advance, choosing N so that the desired accuracy is achieved without unnecessary computational expense.

Validity of the analytical results for BS3SIM:

The simplified model analyzed here differs from the full BS3SIM model in several respects:

In BS3SIM, service times are not necessarily exponentially distributed. However, for the throughput estimator, the key quantity is the asymptotic variance σ², which depends on the full distributional and correlation structure. For non-exponential distributions, σ² would need to be estimated by other means (e.g., batch means or regenerative methods).
In BS3SIM, there are multiple processor cores and multiple transport channels. The Markov chain description extends to higher-dimensional state spaces, but the qualitative conclusions remain valid.
The assumption of job saturation (immediate replacement of a completing segment by a new one) is enforced in BS3SIM when measuring throughput, so this assumption is not a restriction in practice.

Conclusion:

The analytical calculation of the statistical error for the simplified model provides a useful orientation for the choice of simulation run length in BS3SIM experiments. The results confirm that runs of at least several hundred to a few thousand segments are required to achieve errors below 2–3%, and that the worst case occurs when processor core and transport channel speeds are comparable.

[page 390 — continuation / Simulation des Regler Mensch-Verhaltens paper resumes]

Simulation of Controller-Human Behavior in Human-Vehicle Systems

W. Berheide and G. Johannsen Research Institute for Anthropotechnology (Forschungsinstitut für Anthropotechnik), 5309 Meckenheim

1. Introduction

The overall system performance of advanced vehicles of the present and future depends decisively on the capabilities and limitations of the human operator. This gives rise to the following questions, among others, in the development of new human-vehicle systems: What tasks can be taken over or made easier for the human operator by automation? In what cases is the human operator irreplaceable? Various alternatives for the division of tasks between human and automation should be evaluable as early as possible in the design phase. An analytical treatment of this problem, familiar to the systems engineer, becomes possible when the behavior of all subsystems of the closed human-machine control loop — including the system “human” — can be described quantitatively.

For several years, work has been carried out on the development of controller-human simulation models [1], [2], [3]. At the Research Institute for Anthropotechnology, the construction of a program system is currently being begun that is intended to facilitate the systematic further development and comparison of various simulation models. In addition, the models are to be validated for a broad spectrum of vehicle guidance tasks. The status of current preliminary planning is reported in this contribution.

2. Introductory Example for Model Development

The general problem formulation for the present simulation problem is clarified by the example shown in Figure 1.

The human-vehicle control loop (upper part of the figure), in which the human operator takes over the guidance of a vehicle, is compared with the controller-human model-vehicle control loop (lower part of the figure). From the difference in the manipulated variables and controlled variables, a change in the model parameters is derived by means of a model adjustment strategy according to selected quality criteria. The same reference inputs are fed into the model-vehicle control loop as into the human-vehicle control loop. Both control loops have the same structure. Whereas in experiments with human subjects the vehicle can be a real system or a simulated system, simulation will almost always predominate in the model-vehicle control loop.

[page 391: figure only — Figure 1: Simulation of controller-human behavior. Upper loop: human-vehicle control loop with reference input, human, display, controls, vehicle, and controlled variables. Lower loop: model-vehicle control loop with model adjustment strategy and model optimization, consisting of automatic controller, display dynamics, controller-human model, control element dynamics, and vehicle.]

3. Computer System Used

A hybrid computer system is available for carrying out the tasks. An EAI 680 analog computer is coupled via an interface and coupler from Dornier to a Siemens process computer 306. For the design of the program system described in this contribution, the characteristics of the digital computer used are essentially determining. The principal advantage of a relatively short cycle time of 0.6 μs is offset by the following disadvantages. Interrupt programs are managed in a purely software-based manner via a coordination program for fast alarms, with program switching times on the order of 200 μs. The actual executive program together with the coordination program and the necessary hybrid system software occupies approximately half of the 32 K (24-bit) core memory. Program switching times managed via the executive program are in the range of 1 ms.

For the problem at hand, the multiprogramming capabilities of the available digital computer are to be used as little as possible, at least in time-critical cases, since the computer system has a relatively slow program switching strategy. In addition, with multiprogramming the available working memory is not utilized economically, since at least in FORTRAN, extensive system software (e.g., for input/output) is linked to each individual program. FORTRAN is, however, to be used to a large extent for the individual programs because of the desired user-friendliness. The limited available working memory makes it advisable to use overlay techniques as intensively as possible in the less time-critical parts of the program flow.

[page 392]

4. Procedure for Analysis and Simulation of Controller-Human Behavior

The behavioral analysis and simulation of the controller human is carried out in three phases:

Experiment execution and data acquisition,
Experiment evaluation, and
Model development and validation.

Corresponding to the three phases of behavioral analysis and simulation, there are three levels of the program system, each constructed in modular fashion. The experiment evaluation is performed digitally. The other two levels contain hybrid program components. Whereas experiments with human subjects must be real-time program runs, model optimizations run in as strongly compressed a time scale as possible in order to save computation time.

4.1 Experiment Execution and Data Acquisition

In the first phase, experiments with human subjects are conducted. A control program with experiment sequence control has command over the individual program components (see Figure 2). This program is rewritten by the experimenter for each experimental series or assembled from existing program components. The experiment sequence control takes over the setting of initial conditions and operating modes on the analog computer, provides instructions to the experimenter and the test subject via screen or teletype, starts the simulation programs, and controls and monitors the temporal sequence of the experiment.

Reference variables and disturbance variables can be deterministic or stochastic processes. Stochastic processes are generated either by analog noise generators or digital pseudo-noise generators. Whereas the analog generation of reference and disturbance variables can take place within the framework of the vehicle simulation, the function generation programs take over this task in the digital domain.

The vehicle simulation is a hybrid program. For methodological and cost reasons, the vehicle dynamics are most often simulated with one computer. A test cabin connected to the computer system contains display devices and controls at the interfaces between human and vehicle. Programs for display information preprocessing are used for image generation and for computations of derived quantities, e.g., lead (preview) displays. In data acquisition, the problem is to store as many data as possible from discrete and continuous processes in as short a time as possible. In particularly time-critical cases, data will be transferred directly to disk storage. Where time permits, data reduction and conversion will be performed online.

[page 393: figure only — Figure 2: Experiment execution and data acquisition. Block diagram showing: Control Program 1 with experiment sequence control → Function generation (e.g., reference and disturbance variables), Vehicle simulation including automatic controller, Display information preprocessing, Data acquisition (with Online Data Reduction sub-block).]

4.2 Experiment Evaluation

The experiment evaluation is carried out largely offline. It is intended, however, to consider incorporating this program phase partially into the experiment execution at a later stage, with an enlarged core memory and for less time-critical experiments. The core of this program system is the evaluation routines (see Figure 3). It consists of programs for statistical methods, e.g., analysis of variance, and programs for signal and system analysis of stochastic processes.

Using correlation methods, a statistical analysis of signals is performed. Signal properties are described by characteristic quantities and functions such as correlation, distribution, and power spectral density functions. From these, a linear system description — e.g., for the controller human — can be derived in the frequency domain. Furthermore, the nonlinear system properties are investigated. Data input, output, and preparation are handled by data management programs. Various plotting programs are written for the presentation of results.

[page 394: figure only — Figure 3: Experiment evaluation. Block diagram showing: Control Program 2 → Data handling, Evaluations (Statistics / Stochastics), Plotting programs.]

4.3 Model Development and Validation

The actual model development is generally also performed offline (see Figure 4). Models of various degrees of complexity and different structure are validated against the available experimental data and partially compared with one another.

In addition to parameter-free models that result directly from the experiment evaluation, or models computed by methods of optimal control theory, there are models whose parameters are optimized with the aid of an adjustment strategy. These models can consist of digital programs or can also contain analog elements. Optimization programs (e.g., continuous parameter optimization, discrete gradient methods, search methods) are used to realize various adjustment strategies. In doing so, various criterion functions are employed, such as mean squared error and root-mean-square error.

[page 395: figure only — Figure 4: Model development and validation. Block diagram showing: Control Program 3 → Controller-human models, Criterion functions, Optimization methods, Data handling, Vehicle simulation and display/control-element dynamics.]

5. Problems in Implementing the Program System

The program flow in phases 1 and 3 deserves special attention, since hybrid program components are involved. One or more simulation programs run as clock programs with high priority. The preparation of these clock programs includes constructing the commands for the hybrid simulation and releasing the corresponding clock inputs. This task is taken over by the control program before the actual program run. Since the hybrid software used for this purpose is quite extensive, it is advisable to run this preparatory part in an overlay structure. The clock programs are independent main programs and can be linked with existing subroutines.

Within the framework of the control program, the data acquisition or data management program runs as a background program during the simulation and actual program phase. It is interrupted at each step by the clock program and, when not performing data processing, runs in a waiting loop. In data acquisition, a double buffer is used. Data from the experiment are taken into one buffer while data from the other are transferred to disk. The data acquisition program can call data reduction or data management programs as desired.

[page 396]

In the program system there are a number of subroutines — e.g., optimization methods, controller-human models, function generation programs — that are to be stored in a library on disk storage and can be called arbitrarily. These consist for the most part of FORTRAN subroutines or assembly programs that can be invoked with FORTRAN calls. From the requirement that programs of the same kind within one functional block (e.g., optimization programs) be arbitrarily interchangeable, it follows that these programs must have the same number and type of parameters. The parameters of “sub-subroutines,” which can themselves also be arbitrarily exchanged, must be passed along as well.

From the requirement for variable experiment or evaluation intervals, it follows that the arrays of the programs must be variable in size. This is the main reason why the subroutine technique with passing of actual parameters is used extensively and COMMON areas are avoided. Since approximately 20 μs of computation time is consumed per parameter transfer, consideration is being given to modifying the transfer method or passing as many parameters as possible together in a single array.

It is expected that the described modular construction of the program system, taking into account the available computer system, represents an optimal adaptation to the changing questions of the research field “controller human.” At the same time, it is hoped that the status of current considerations can provide stimulation for the approach to related simulation tasks. It is simultaneously hoped that stimulation for further work can be gained from this workshop.

References:

[1] McRuer, D. T. and Jex, H. R.: A review of quasi-linear pilot models. IEEE Trans. Human Factors in Electronics, vol. HFE-8, pp. 231–249, Sept. 1967.

[2] Kleinman, D. L., Baron, S., and Levison, W. H.: An optimal control model of human response, Part I: Theory and validation. Automatica, vol. 6, pp. 357–369, May 1970.

[3] Johannsen, G.: Development and optimization of a nonlinear multiparameter human operator model. IEEE Trans. Syst. Man Cybern., vol. SMC-2, pp. 494–504, Sept. 1972.

[page 385 / PDF p. 397]

(Ia) Definition of Random Variables

The random variables are defined as follows:

$$f = \begin{cases} 1 & \text{if } E(t) = E_i \ 0 & \text{if } E(t) \neq E_i \end{cases}$$

In a simulation experiment with N events, the value for BRK is obtained according to the following formula:

(11)

$$\text{BRK}(N) = 1 - \frac{\displaystyle\sum_{n=1}^{N} \text{ABW}(n) \cdot \Delta t(n)}{\displaystyle\sum_{i=0}^{\infty} \sum_{n=1}^{N} S_i(n) \cdot \Delta t(n)}$$

The probability distribution of the random variable $S_j(n)$ is:

$$P\bigl[S_j(n) = 1\bigr] = p_j^{(2n)}$$

$$P\bigl[S_j(n) = 0\bigr] = 1 - p_j^{(2n)}$$

for $E_i, E_j \in G_1,; i, j = 1, 2, \ldots$

It can be seen that the random variables $S_i(n)$ for fixed $i$ and $n = 1, 2, \ldots, N$ are not all mutually independent. If it is established in step $n$ that $S_i(n)$ equals 1, then the distribution $P_j(n)$ of the states $b_{ij}$ ($\delta$ = Kronecker symbol) is thereby determined.

Let $E_i \in G_1$. The “memory” of the distribution of the states from $G_1$ is lost only after waiting so many periods $K$ that the distribution $P_{ij}(2K)$ of the states $G$ is independent of the distribution $\delta_{ij}$.

The goal is to have only statistically mutually independent summands in the computation of BRK. It is first noted that there are three types of the random variables $\Delta t(n)$:

[page 386 / PDF p. 398]

The $\Delta t(n)$ possess, when the processor core is idle, the distribution $1 - e^{-\lambda t}$: $$\Delta t(n) := \Delta t_A(n)$$
The $\Delta t(n)$ possess, when the processor core and the transport channel are occupied, the distribution $1 - e^{-(\gamma + \lambda)t}$: $$\Delta t(n) := \Delta t_B(n)$$
The $\Delta t(n)$ possess, when the transport channel is idle, the distribution $1 - e^{-\gamma t}$: $$\Delta t(n) := \Delta t_C(n)$$

From this it follows:

(13)

$$\text{BRK}(N) = \frac{A(N)}{A(N) + B(N) + C(N)}$$

where $A(N)$, $B(N)$, $C(N)$ are defined by the respective sums.

The statistically dependent summands in the expressions for $A(N)$, $B(N)$, and $C(N)$ are now removed, taking into account that an average is formed over one period. The result is then:

(14)

$$A(N \cdot K) = \sum_{n=1}^{N} \Bigl[ S_0(n,K) + S_0(n,K+1) \Bigr] \cdot \Delta t_A(n,K)$$

(15)

$$B(N \cdot K) = \sum_{i=1}^{\text{ABW}-1} \sum_{n=1}^{N} \frac{S_{iB}(n,K) + \frac{1}{2} S_{iB}(n,K+1)}{N} \cdot \Delta t_B(n,K)$$

(16)

$$C(N \cdot K) = \sum_{n=1}^{N} \frac{\text{ABW}(n,2K) + \text{ABW}(n,K+1)}{N} \cdot \Delta t_C(n,K)$$

Without loss of generality, $\tilde{S}_j(n, K+1) = 0$ can be assumed. Through averaging over the period, it is no longer necessary to distinguish between the groups $G_1$ and $G_2$.

[page 387 / PDF p. 399]

In expressions (14), (15), (16) it is only necessary to consider the random variable $\tilde{S}_i(n) = \frac{1}{2}[S_i(n,K) + S_i(n,K+1)]$.

The distribution of this random variable is:

(17)

$$P\bigl[\tilde{S}_i(n) = 1\bigr] = U_i$$ $$P\bigl[\tilde{S}_i(n) = 0\bigr] = 1 - U_i$$

For $N$ tending to infinity, the following limits are obtained:

(18)

$$\lim_{N \to \infty} A(N,K) = U_0 \cdot E(\Delta t_A)$$

(19)

$$\lim_{N \to \infty} B(N,K) = \sum_{i=1}^{\text{ABW}-1} U_i \cdot E(\Delta t_B)$$

(20)

$$\lim_{N \to \infty} C(N,K) = U_{\text{ABW}} \cdot E(\Delta t_C)$$

$\Delta A$, $\Delta B$, and $\Delta C$ denote the statistical errors of $A$, $B$, and $C$ respectively. The statistical error of BRK is thereby:

(21)

$$\Delta \text{BRK} = \left|\frac{\partial \text{BRK}}{\partial A}\right| \Delta A + \left|\frac{\partial \text{BRK}}{\partial B}\right| \Delta B + \left|\frac{\partial \text{BRK}}{\partial C}\right| \Delta C$$

For the relative error of $d$ (respectively $D$), taking into account that $E(t_{RK})$ is determined from the input data of the simulation and therefore carries no error:

(22)

$$\frac{\Delta D}{D} = \frac{1}{A+B+C} \sqrt{\Delta A^2 + \Delta B^2 + \Delta C^2}$$

For the statistical errors $\Delta A$, $\Delta B$, and $\Delta C$, it follows from (18), (19), and (20):

(23)

$$\Delta A = \frac{\Delta U_0}{\text{ABW}} \cdot E(\Delta t_A) + U_0 \cdot \Delta E(\Delta t_A)$$

(24)

$$\Delta B = \sum_{i=1}^{\text{ABW}-1} \left( \Delta U_i \cdot E(\Delta t_B) + U_i \cdot \Delta E(\Delta t_B) \right)$$

(25)

$$\Delta C = \frac{\Delta U_0}{\text{ABW}} \cdot E(\Delta t_C) + \frac{U_{\text{ABW}}}{\text{ABW}} \cdot \Delta E(\Delta t_C)$$

[page 388 / PDF p. 400]

The statistical errors

(26)

$$\Delta U_i = \sqrt{\frac{U_i(1-U_i)}{N}}$$

(27)

$$\Delta E(\Delta t_{A,B,C}) = \left| \sum_{n=1}^{N} \Delta t_{A,B,C}(n) - E(\Delta t_{A,B,C}) \right|$$

can be estimated using the Chebyshev inequality.

From the Chebyshev inequality it follows that for pairwise independent random variables $X(1), \ldots, X(N)$ having the same distribution, the following holds for any positive $\varepsilon$:

$$P\left[\left|\frac{1}{N}\sum_{n=1}^{N} X(n) - a\right| \geq \varepsilon\right] \leq \frac{\sigma^2}{N \varepsilon^2}$$

where $a$ is the mean value and $\sigma$ is the standard deviation of the variable $X(i)$.

The mean values and standard deviations of the various random variables are summarized in the following table:

(28)

Random variable	$\Delta t_A$	$\Delta t_B$	$\Delta t_C$
Mean value	$1/\lambda$	$1/(\lambda+\gamma)$	$1/\gamma$
Standard deviation	$1/\lambda$	$1/(\lambda+\gamma)^2$	$1/\gamma^2$

Additionally, for $U_i$: mean value $= U_i$, standard deviation $= \sqrt{U_i(1-U_i)}$.

A boundary probability $P_{\text{GRENZ}}$ is specified, with which the errors $\Delta U_i$ and $\Delta E(\Delta t_{A,B,C})$ are allowed to exceed certain positive numbers:

[page 389 / PDF p. 401]

$$\delta \leq P_{\text{GRENZ}}$$

$$j \geq \sqrt{\frac{1-P_{\text{GRENZ}}}{P_{\text{GRENZ}}}} \cdot \varepsilon$$

For the various random numbers the following values for $\varepsilon$ result:

$$\varepsilon_{\Delta U_i} = \frac{1}{N \cdot P_{\text{GRENZ}}}$$

$$\varepsilon_{\Delta t_A} \cdot P_{\text{GRENZ}},\quad \varepsilon_{\Delta t_B} \cdot P_{\text{GRENZ}},\quad \varepsilon_{\Delta t_C} \cdot P_{\text{GRENZ}} \cdot N \cdot P_{\text{GRENZ}}$$

(Meaning of $L_{A,B,C}$: see (27))

The relative error of the throughput $D$ can now be computed as follows: the number $K$ of periods until the Markov chain is practically stationary is determined. Then equation (4) is solved and, after normalization of the solution, the stationary distribution of the states is obtained. If the number $S$ of steps in the simulation experiment is known, then $N$ is obtained by dividing $S$ by $2K$. Using (22), (23), (24), (25), (28), and (29), an error bound $F_{\text{GRENZ}}$ for $\Delta D / D$ is determined. It is exceeded with probability at most $P_{\text{GRENZ}}$. $F_{\text{GRENZ}}$ is proportional to:

(30)

$$F_{\text{GRENZ}} \sim R \cdot \sqrt{\frac{P_{\text{GRENZ}}}{N}}$$

$R$ is a function of $\gamma$, $\lambda$, and $U_i$.

[page 390 / PDF p. 402]

One uncertainty in the error calculation lies in the choice of the number $K$ of periods after which the Markov chain is considered stationary.

An important restriction of formula (30) is that $F_{\text{GRENZ}}$, due to the linear approximation (21), takes into account only first-order errors. However, it can be seen that $n$-th order errors contain the factor $(1/N)^n$, so that for $N > 100$ errors of order higher than 1 can be neglected.

I. Throughput Gain D/D₀

Through the mathematical solution of the computer model, it has also become possible to compute the relative gain in throughput when transitioning from single-programming to multi-programming.

With an unchanged job profile, the result is:

(31)

$$D/D_0 = \text{BRK} / \text{BRK}_0$$

where:

$D$ = throughput under multi-programming
$D_0$ = throughput under single-programming
$\text{BRK}$ = relative processor-core utilization under multi-programming
$\text{BRK}_0$ = relative processor-core utilization under single-programming

In Figure 2, $D/D_0$ is plotted as a function of computing intensity RI (RI = mean computation time / mean transport time) (the associated value table is given in Table 1).

[page 391 / PDF p. 403]

II. Number of Steps Until Stationarity of the Markov Chain

The distribution $p^{(n)}$ of the states after $n$ steps is obtained from the initial distribution $p^{(0)}$ by the formula:

$$p^{(n)} = (P^n)^T \cdot p^{(0)}$$

According to (3) and (4), for every arbitrarily small positive real number $\varepsilon$ there exists a positive integer $K$ such that:

For $p_i(2K) \neq 0$:

(32)

$$\left| \frac{p_i(2K) - 2U_i}{2U_i} \right| \leq \varepsilon$$

and for $p_j(2K+1) \neq 0$:

(33)

$$\left| \frac{p_j(2K+1) - 2U_j}{2U_j} \right| \leq \varepsilon$$

As initial distribution, the distributions $P_j = \delta_{ij}$ are appropriate, because at the moment of observation of the model state at certain time points, exactly one state $E_i$ has been reached.

Table 2 gives values for $K$ at $\varepsilon \leq 10^{-1}$ and the initial distribution $P_i = \delta_{ij}$ as a function of computing intensity RI (RI = mean computation time / mean transport time) and the number ABW of program slots.

III. Number of Events; Simulation Time

The number $S$ of events determines the statistical error of the throughput. $S$ is given by:

(34)

$$S = 2 \cdot K \cdot N$$

where $K$ is the number of periods until the Markov chain can be considered stationary, and $N$ is the number of observation time points at which information is collected. The mean interval $E(\Delta t)$ between events can be computed with the following formula:

[page 392 / PDF p. 404]

(35)

$$E(\Delta t) = \frac{1}{\lambda U_0 + \displaystyle\sum_{i=1}^{\text{ABW}-1} (\lambda+\gamma) U_i + \gamma U_{\text{ABW}}}$$

The mean value $E(T)$ of the simulation time $T$ is thus:

(36)

$$E(T) = S \cdot E(\Delta t)$$

From Table 3, the values of the proportionality factor $R$ in formula (30) can be read.

Table 4 contains the number $S$ of events after which the throughput $D$, computed via BRK, exceeds a statistical error of $F_{\text{GRENZ}} = 10^{-1}$ with probability at most $P_{\text{GRENZ}} = 10^{-2}$. Since a linear approximation was used in estimating the statistical error of $D$, all fields with $N \leq 100$ must remain empty, because in this case errors of order higher than 1 may play a role. Table 5 gives the corresponding mean values $E(T)$ of the simulation time $T$; in the computation of $E(T)$, besides the computing intensity $RI = \lambda/\gamma$, also $\gamma$ or $1/\gamma$ enters; the value $1/\gamma = 50$ (ms) has been used as the basis, since a background transport to the drum averages approximately 50 ms. Formally speaking, the time unit is arbitrary.

6. Discussion of Results

Regarding 5.I.: With the mathematical treatment of the computer model, a way has been shown how one can compute the job throughput for arbitrary computer models with the single restriction that service times are exponentially distributed. It is only necessary to find an appropriate set of states whose distribution is complete ($\sum P_i = 1$). For demonstration, a computer model with 1 processor core and 2 transport channels and a queue for each resource is considered. The set of states would then look as follows:

$A_i$ (respectively $B_i$, respectively $C_i$) stands for “the RK [processor core] queue (respectively TK [transport channel] queue 1, respectively TK queue 2) is occupied by $i-1$ jobs.”

The set of states then consists of the elements $E_{i,j,k} = {A_i \text{ and } B_j \text{ and } C_k}$, $i, j, k = 1, \ldots, \text{ABW}+1$.

In setting up the transition matrix, the same procedure as for the simpler model of this study can be followed; the distribution of service times and the access probabilities yield the transition probabilities $P_{ij}$ from state $E_i$ to states $E_j$.

[page 393 / PDF p. 405]

Regarding 5.III.: For throughput determination by simulation according to (9), with I/O-intensive job mixes, considerable simulation times are required if one wishes to ensure that the error does not exceed 10% with high probability of at least 0.99. Using (10), a different determination of throughput is possible.

The states $E_0, \ldots, E_{\text{ABW}}$ of the transport channel queue are denoted, i.e., $E_i$ is present when the queue is occupied by $i$ transport jobs.

Because $U_i = U_{\text{ABW}-i}$, the following results:

[page 394 / PDF p. 406]

(38)

$$\frac{\text{ABW}-1}{\displaystyle\sum_{i=0}^{\text{ABW}} 2U_i + U_{\text{ABW}}} = \frac{\lambda/\mu}{\displaystyle 1 - U_{\text{ABW}}} + \frac{\lambda + \gamma}{\displaystyle\sum_{i=1}^{\text{ABW}-1} U_i} + \frac{\lambda}{U_0}$$

Expression (38) differs from the corresponding expression BRK only in that $\lambda$ and $\gamma$ are interchanged. From this it follows:

If $d$ is computed at $RI = 0.25$ using (10), the same statistical error will be obtained as when computing $d$ using (9) at $RI = 4.0$.

At $RI = 1$, the statistical errors of (9) and (10) are equally large. When 1 ms is taken as the time unit, under the assumptions stated above, approximately a simulation time of two hours results. This represents the most unfavorable case, when $d$ is computed using (10) for $RI \leq 1$, and using (9) for $RI > 1$.

[page 395 / PDF p. 407 — Table 1]

Table 1: $D/D_0$ as a function of computing intensity RI and number of program slots

RI \ Program slots	2	3	4	5	6	7
0.2	1.16	1.19	1.20	1.20	1.20	1.20
0.4	1.26	1.34	1.38	1.39	1.40	1.40
0.6	1.31	1.44	1.51	1.55	1.57	1.58
0.8	1.33	1.49	1.58	1.64	1.68	1.71
1.0	1.33	1.50	1.60	1.67	1.71	1.75
2.0	1.29	1.40	1.45	1.48	1.49	1.49
3.0	1.23	1.30	1.32	1.33	1.33	1.33
4.0	1.19	1.24	1.25	1.25	1.25	1.25

[page 396 / PDF p. 408 — Table 2]

Table 2: Values of the number $K$ of periods after which the Markov chain is “sufficiently” stationary ($\varepsilon \leq 10^{-1}$, initial distribution $P_i = \delta_{ij}$)

ABW \ RI	0.2	0.4	0.6	0.8	1.0	2.0	3.0	4.0
2	1	1	1	1	1	1	1	1
3	7	9	10	11	11	11	10	8
4	11	16	19	22	20	18	16	13
5	12	20	28	35	34	32	23	18
6	16	27	39	42	52	39	27	22
7	—	29	5x	64	69	58	34	26

[page 397 / PDF p. 409 — Table 3]

Table 3: Values of the proportionality factor $R$ in the formula $F_{\text{GRENZ}} = R \cdot \sqrt{P_{\text{GRENZ}} / N}$

ABW \ RI	0.2	0.4	0.6	0.8	1.0	2.0	3.0	4.0
2	4.1	2.8	1.8	1.2	1.0	0.91	0.85	0.81
3	3.8	2.5	1.6	0.83	0.66	0.56	0.50	0.45
4	3.7	2.4	1.5	8.6×10⁻²	2.4×10⁻²	9.4×10⁻³	—	—
5	3.7	2.4	1.4	5.9×10⁻²	1.4×10⁻²	4.7×10⁻³	—	—
6	3.7	2.4	1.4	4.1×10⁻²	7.9×10⁻³	2.3×10⁻³	—	—
7	3.7	2.4	1.4	2.9×10⁻²	4.5×10⁻³	1.2×10⁻³	—	—

[page 398 / PDF p. 410 — Table 4]

Table 4: Number $S$ of events until the statistical error of $D$ exceeds $F_{\text{GRENZ}} = 10^{-1}$ with probability at most $P_{\text{GRENZ}} = 10^{-2}$

ABW \ RI	0.2	0.4	0.6	0.8	1.0	2.0	3.0	4.0
2	3.4×10⁵	1.6×10⁵	1.6×10⁴	3×10⁴	1.4×10⁴	5×10²	1.2×10²	1.5×10¹
3	2.0×10⁶	1.1×10⁶	5.1×10⁵	2.2×10⁵	9.1×10⁴	3.7×10³	3.7×10²	5.8×10¹
4	3.0×10⁶	1.8×10⁶	8.6×10⁵	3.6×10⁵	1.03×10⁵	2.7×10³	1.08×10²	—
5	3.3×10⁶	2.3×10⁶	6×10⁵	4×10⁵	1.7×10⁵	2.2×10³	9.0×10¹	—
6	4.4×10⁶	3.1×10⁶	1.5×10⁶	8.4×10⁵	2.1×10⁴	1.3×10³	—	—
7	—	4.1×10⁶	3.3×10⁶	2.0×10⁶	7.5×10⁵	2.4×10⁵	1.9×10²	—

[page 399 / PDF p. 411 — Table 5]

Table 5: Mean value $E(T)$ of the simulation time $T$ when the statistical error of $D$ does not exceed $F_{\text{GRENZ}} = 10^{-1}$ except with probability $P_{\text{GRENZ}} = 10^{-2}$ (with $1/\gamma = 50$ ms)

ABW \ RI	0.2	0.4	0.6	0.8	1.0	2.0	3.0	4.0
2	1×10⁶	200	100	8.7	4.5	1.9	1.0	5.3×10³
3	5.0×10⁷	2.9×10⁷	7.8×10⁶	1.6×10⁶	1.3×10⁶	2.0×10⁵	2.9×10⁴	5.8×10³
4	7.5×10⁷	4.5×10⁷	2.2×10⁷	1.0×10⁷	4.0×10⁷	1.4×10⁶	1.4×10⁵	—
5	5.2×10⁷	5.5×10⁷	2.9×10⁷	1.4×10⁷	5.1×10⁵	1.1×10⁵	1.6×10³	—
6	1.1×10⁸	7.8×10⁷	3.7×10⁷	2.3×10⁷	1.6×10⁷	6.5×10⁴	—	—
7	1.0×10⁸	5.3×10⁷	5.0×10⁷	2.0×10⁷	7.0×10⁶	4.9×10³	—	—

[page 400 / PDF p. 412 — figure only]

[page 400: figure only — network/traffic diagram labeled “Verkehrswege des BSS/1” (traffic routes of the BSS/1 system), showing data paths between units including processor core (Rechnerkern), job queue (Auftragsstelle), transport channels, console, sources (Quelle), and various connection paths with annotations for segments (Abschnitte), addressing (Adressierung), and task scheduling/control flow]

[page 401 / PDF p. 413 — figure only]

[page 401: figure only — graph showing simulation results, with axes and curves; appears to be a performance or throughput plot with labeled curves, grid lines, and data points, but no legible axis labels or curve identifiers are recoverable from the text layer]

[page 402 / PDF p. 414]

Experiences with Program-Implemented Simulation Models and Measured Input Data for Behavioral Analyses of Information-Processing Systems, and Concepts for the Step-by-Step Expansion of Operating-System Functions with the Aid of Behavioral Analyses and Simulation of Subsystems

by Erich F. Pantele

Report on the BSM Project. Working Group for Operating Systems, Computing Center of the Technical University of Munich.

0. Introduction and Overview

In this paper two problem areas are discussed that were or are being worked on within the framework of the research project BSM (Betriebssystem München — Munich Operating System).

(1.) An experience report on the investigation of the TR 440 address-transformation mechanism by means of simulation. The following are explained in detail:

(1.1.) The reasons for the selection of the method
(1.2.) Problems with the selection of data material and experiment duration
(1.3.) The validity assessment of the results

(2.) Preparations for the step-by-step performance improvement of the BSM operating system, with the following concepts particularly highlighted:

(2.1.) The planning-in of measurement facilities during development of the operating system
(2.2.) Systematics in the decomposition into subsystems
(2.3.) Systematics in the handling of the improvement phases

At the end, the problems characteristic of such work are evaluated together once more.

1. A Field Report on the Investigation of the TR440 Address-Transformation Mechanism by Means of Simulation

Initial Situation

The Telefunken computer TR440 contains a hardware facility in the form of four electronic associative registers designed to accelerate the main-memory addressing process. In the steady state these associative registers hold the four most recently used distinct reference pairs consisting of a page number (from the virtual address space of a program-implemented functional unit) and a frame number (from real main memory). These four page–frame reference pairs are each a subset of the complete mapping function — page numbers of the address space to frame numbers of the real main-memory location — which exists in the form of a page–frame table. The performance of the computer (here: average instruction-execution speed) depends relatively strongly on the relative frequency with which, during a memory-addressing operation, the required page-number–frame-number mapping is found in the (fast) associative registers (rather than an additional main-memory access being required to read the page–frame assignment from the page–frame table).

The objective of the investigation is to test the effectiveness of the associative registers in accelerating the addressing operations and to make qualitative and quantitative statements about the influencing parameters. (Ref. 5)

1.1. Reasons for Selecting the Simulation Approach

Of the two alternatives — direct investigation with hardware facilities, or measurement and simulation using software methods — the software method was preferred for the following reasons:

Modifications to the computer hardware to attach measurement probes entail unacceptably large security risks for ongoing operation, or excessively high implementation costs.
Hardware measurements cannot yield the necessary findings about the characteristic parameters of the “job profile” on the object under investigation; however, when the job profile is obtained by software means, characteristic parameters and correlations can be found conveniently.
Altering the object under investigation for simulation purposes (e.g., changing the number of registers) is very difficult to accomplish in hardware — but correspondingly straightforward in a programmed simulation model.

Accordingly, the simulation was carried out using a programmed simulation model in which the number of registers was variable, and on which a “job profile” in the form of address-reference sequences was applied.

(page 404)

These sequences were obtained from the real system using a software-based recording procedure. From this job profile, both before and during acquisition by recording and during simulation, characteristic parameters such as the following could be determined:

Program size in pages
Dynamic address-reference behavior of a program run within its address space (locality)
Frequency of transient settling operations caused by invalidation of register contents upon changes of addressing mode or upon control transfers to the address spaces of other functional units in multiprogramming

1.2. Problems with the Selection of Data Material and with Experiment Duration

Generating a representative job profile for the simulation model was the most difficult task. On the real system the job profile governing the addressing procedure is constituted by the combined influence of many machine-instruction sequences generated by various compilers, from various user problems with differing programming styles, algorithms, program sizes, data sets, etc.

For the acquisition of address-reference sequences, programs were therefore run that were oriented — at least in principle — toward the real conditions of user operation.

The ratio of 2.5 hours of simulation computing time per 10 seconds of original computing time permits only a minimal sample selection from the computing workload.

Note: The 2.5 hours of simulation computing time breaks down as 1 hour of recording time for address-reference sequences and 1.5 hours of computing time for the simulation program processing the data.

The sample selection could therefore only be oriented toward the frequency of use of system operators, language compilers for user programs, and memory-requirement figures observed over a period of more than 3 weeks of real operation.

Since, for computing-time reasons, no user programs with longer execution times (> 20 sec) could be considered, corresponding qualifications must be made when interpreting the results.

1.3. Validity Considerations for the Results

The interpretation of results must take into account the limitations in sample selection mentioned in Section 1.2. In the present case, 64 program runs were evaluated, which together encompass approximately 35 million address transformations. This corresponds to an original computing time of approximately 70 seconds.

The systematic selection of program runs is not a sample selection in the statistical sense and therefore does not permit statistical interpretation of the results.

(page 405)

Accordingly, only the mean, minimum, and maximum values of the relative frequency of occurrence of the event E = “The page–frame assignment was found in the associative registers” are presented, as a function of the number of associative registers, for the evaluated program runs.

[page 405: figure — graph of relative frequency E versus number of associative registers (1–12), showing mean, minimum, and maximum curves for the evaluated program runs, with frequency values ranging from approximately 0/16x to 1/1x on the y-axis]

The following can be stated as an assessment of the method:

The model program proved very effective, since in addition to the relative frequency for E shown above it simultaneously delivered other relationships as results, such as:
- h_E as a function of the program’s memory size
- h_E as a function of the locality character of the program run
- h_E as a function of the density of addressing-mode interruptions caused by system calls
The long run time for a single simulation pass is, however, a major disadvantage.
The procedure for obtaining the simulation data is very disadvantageous, since beyond the acquisition of real memory-access sequences it was not possible:
- to take statistically based samples of arbitrary length from arbitrary program runs at arbitrary times (only complete operator runs were possible), and
- to perform this data acquisition alongside fully running computing operations on the machine (only in isolated operation).

(page 406)

2. Preparations for Stepwise Performance Improvement of the Operating System BSM

Initial Situation

BSM is an operating system consisting of a hardware-close base system and a set of independent functional units (processors) through which the system services are rendered. These functional units can operate asynchronously in parallel on the two-processor TR440 installation. A layered structure is defined within the set of functional units, so that a certain hierarchy exists in the availability of system services. At the highest hierarchical level, system management and user jobs are placed. (Refs. 1, 2)

In this operating system, which is currently in the implementation stage, algorithms for operating strategies are incorporated at various points (e.g., access algorithms for rotating storage devices, page-replacement algorithm for demand paging, resource-allocation and scheduling algorithms). Such operating strategies are, in the first approach, generally implemented in a relatively simple form.

The objective is to simulate a job environment whose characteristic parameters are to be known — using characteristic job loads (benchmark programs) — for the system or subsystems, and to observe the system behavior. Based on these observations, the operating algorithms of the system are to be improved in accordance with operating policy.

2.1. Incorporation of Measurement Facilities During Development of the Operating System

A capable measurement system as an integrated component of the operating system is a necessary prerequisite for conveniently obtaining information about system behavior. For this purpose, BSM provides a so-called central log dispatcher (as a central collection point for information deposits) and various means for convenient information output, such as:

Execution recording
Service for direct deposit of brief information
Dump service
Enable/disable capability for test and measurement routines that are components of system parts

These facilities make it possible to record information about observable events in the order of their occurrence and to route it to external data carriers. The sequentially stored set of self-describing information elements can be evaluated by an analysis program in various configurable versions. (Ref. 6)

(page 407)

2.2. Systematic Decomposition into Subsystems

For the investigation of functional relationships in the operating system it is expedient to regard the system as divided into subsystems. The layer boundaries within the system provide suitable demarcations for the underlying “pseudomachines” m_k as subsystems. For each m_k, the pseudomachine m_{k+1} lying above it is to be represented only in the form of a characteristic job profile. The pseudomachine m_k itself is to be observed — with the job load characteristic of it, in the sense of defined task specifications — and improved where necessary. In addition to the layered partitioning of the system, a lateral partitioning within a single m_k is also meaningful when only a segment of the service offering is to be subjected to improvement and parts of m_k are not affected.

2.3. Systematic Execution of the Improvement Phases

Carrying out an improvement step requires knowledge of:

A — the system parameters governing behavioral regulation of the (sub-)system,
B — the target behavior of the (sub-)system,
C — the characteristic parameters of the job load,
D — the actual behavior of the (sub-)system.

For an improvement of the object m_k the following applies:

The system parameters of m_k are determined — with their qualitative and quantitative influence on the object’s behavior — by simulation with special job loads of known characteristics.
The target behavior of the object must be defined as the working objective.
A sufficiently general job load for the object must be obtained (by measurement).
Using the general job load, the actual behavior of the object is determined by measurement, and
from the comparison of actual and target values, the consequence for the setting of system parameters or modification of the object must be drawn.

(page 408)

Note: Steps 4 and 5 represent a simple feedback control loop:

[page 408: diagram — schematic of the control loop showing “Load” as input, the system object m_k in the forward path, and feedback comparing actual behavior (D) against target behavior (B), with the system parameters (A) as the controlled variable]

The operating system, which will require improvement after completion of the first prototype, can — by virtue of its layered structure — be decomposed into a sequence of nested “pseudomachines” m_k, for example:

m_0 = system with all functional units (FU)
m_1 = system without FU
m_2 = system kernel
m_3 = base system

[page 408: diagram — hierarchical nesting diagram showing m_0 through m_3 as nested layers]

For each of the m_k, the above points 1 through 5 can be applied for an improvement.

Improvement of the overall system proceeds from “inside outward” in the sense of a cascade control in control theory.

It must be noted that when m_k is modified, all m_{k+1} through m_n must be subsequently improved as well, since, due to the system’s inherent job direction, their job load and therefore their behavior may have changed.

(page 409)

3. Summary

The first example was intended to show what problems arise from the absence of suitable measurement facilities for data acquisition needed for simulations and other observations.

The second example was intended to show that an appropriate system structure and the early incorporation of measurement facilities can facilitate behavioral analyses, simulations, and improvements on highly complex objects.

Literature References

(1) G. Goos, J. Jürgens, K. Lagally: The Operating System BSM, Viewed as a Community of Parallel Processes; March 1972, Report 7208, MI-TU Munich.

(2) K. Lagally: Invocation of System Services in a Hierarchically Structured Operating System. 2nd GI Annual Conference, Oct. 1972, Karlsruhe.

(3) G. Mersmann: Planning of Measurement Methods in a Time-Sharing Computer System. NTG/GI Specialist Conference “Computer and Operating Systems: Analysis, Simulation, and Design”, April 1972, Darmstadt.

(4) G. A. Mihram: Simulation, Statistical Foundations and Methodology; Academic Press, 1972.

(5) E. F. Pantele: A Measurement Method and Some Measurements on the Dynamic Behavior of Program Runs in the Main Memory of a Digital Computer. NTG/GI Specialist Conference “Computer and Operating Systems: Analysis, Simulation, and Design”, April 1972, Darmstadt.

(6) E. F. Pantele: Incorporation of a Capable Software Measurement System During the Development of an Operating System. 2nd GI Annual Conference, Oct. 1972, Karlsruhe.

(page 410)

Results of the Participant Survey for the Simulation Workshop

The participant survey was intended to provide an overview of the composition of the discussion group and, in particular, to give information about the working environment and the participants’ prior experience with simulation and simulation aids.

The survey results presented here can naturally be considered representative only for the simulation workshop itself, and even then only to a limited degree, since some questionnaires were not returned at all or were only partially completed (see below).

Furthermore, it must be taken into account that in some cases entire working groups were represented at the workshop, which was reflected in several identically answered questionnaires and led to a distortion of results (especially in Point 4).

Nevertheless, the survey results are believed to offer the participants of the workshop a certain overview and should therefore not be withheld from them.

(page 411)

1. Number of participants: 45
Questionnaires returned: 34

2. Overview of the Participant Group

Category	Count
Working with discrete systems	25
Working with continuous systems	13

Field of activity	Count
University	13
Industry	13 (of which 9 computer manufacturers)
Research center	8
Other	4

3. Breakdown of Participants by Duration of Experience (years)

[page 411: table — distribution of continuous and discrete simulation practitioners by years of experience (0, 0.5, 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5, 6–12), totaling 13 continuous and 25 discrete]

(page 412)

Simulation languages/tools used, by duration of experience (years):

Language	0.5	1	1.5	2	2.5	3	3.5	4	4.5	5	6–12	Total
ALGOL
ANAGOL
APL/360
ASIM			1									1
ASSEMBLER				1								1
CSMP
DYNAMO
FORTRAN	1		1	2		2		1		2	3
GPSS	1	2	2	1	2	1		1		1	2
SIMSCRIPT 1.5				2	3			2	1		1
SIMSCRIPT II						1					1
SIMULA I					1
SIMULA 67	2		1	2		2	1	1		2	2

(The table is incomplete. Additional languages cited by individual participants were: BASIC, DYSYS, GASP, PL/1, as well as in-house developments such as SAMO.)

Criteria cited for language selection:

Criterion	Count
Machine configuration and compiler	15 times
(Planned) application	17 times

(page 413)

4. Overview of computer systems available to participants:

System	Count
TR 440	15
TR 4	—
TR 86	—
CDC 6600	—
CDC 6500	—
IBM/360-40	—
IBM/360-50	—
IBM/360-65	—
IBM/360-67	—
IBM/360-85	—
IBM/370-155	10
IBM/370-165	—
IBM/370-195	2
Siemens 4004/151	3
Siemens 306	—
Electrologica X8	5
Univac 1108	12
PDP-10	4
EAI 680	1
P 1400	3
HRS 860	1
HSI SS 100	2
SDS/Beckmann EASE	1

(Note: counts as extracted from the original table; some entries in the source table are partially illegible due to OCR artifacts.)

5. Occasion for work in the field of simulation:

Occasion	Count
1. Personal initiative	6
2. Ongoing project	17
3. Both 1 and 2	10
4. No information given	1

ABW \ RI	0.2	0.4	0.6	0.8	1.0	2.0	3.0	4.0
2	1	1	1	1	1	1	1	1
3	7	9	10	11	11	11	10	8
4	11	16	19	22	20	18	16	13
5	12	20	28	35	34	32	23	18
6	16	27	39	42	52	39	27	22
7	—	29	5x	64	69	58	34	26

ABW \ RI	0.2	0.4	0.6	0.8	1.0	2.0	3.0	4.0
2	1	1	1	1	1	1	1	1
3	7	9	10	11	11	11	10	8
4	11	16	19	22	20	18	16	13
5	12	20	28	35	34	32	23	18
6	16	27	39	42	52	39	27	22
7	—	29	5x	64	69	58	34	26

Methodik der rechnergestützten Simulation — Fachgespräche vom 10.–11. Mai 1973

Methodology of Computer-Aided Simulation

Workshop Proceedings, 10–11 May 1973

Summary: Methodology of Computer-Aided Simulation

Abstract: Computer Simulation Methodology

Preface

Table of Contents

Use and Design of Systems for the Real-Time Simulation of Time-Continuous Systems

1. Introductory Remarks on Model Formation and Depth of Modeling

2. Representation of the Subsystems

3. Special Problems of the Mixed Use of Digital and Analog Models and Real Hardware Components

[Pages 19–36: Chapter continuation — Hybrid Simulation, Practical Setup (Dornier)]

[Page 19 — continued from prior section]

4. Computer Configuration

5. Programming Language

6. Mode Control by HYBRIDMASTER

[Page 20]

7. Temporal Sequence Within a Clock Step, Real Time — Achievable Clock Intervals

[Page 21]

8. Integration of Real Hardware into the Simulation Process

[Page 22]

9. Limits of Hybrid Simulation — Outlook

[Page 23]

[Page 24 — figure only]

Logical and Functional Simulation of a Complex Hardware Control System for Data Preprocessing

1. Introduction

2. Structure and Simulation of the Control System

2.1 Structure and Mode of Operation

2.2 Logical Simulation of the Data Preprocessing Unit

2.3 Functional Simulation of the Data Preprocessing Unit

3. Concluding Remarks

4. References

Dynamic Simulation as a Decision-Making Aid in Educational Planning

Abstract

Introduction

General Approach

Development of the Behavioral Model

Variables, Parameters, Dependencies

System Structure

[Pages 55–72: Student Behavior Simulation Model — Results and Conclusions]

Financial Sector

Simulations

Further Investigations

Overview of Simulation Results

Conclusion

Bibliography

A Program System for the Simulation of Road Traffic Systems

Page 73

Page 74

Page 75

Page 76

Page 77

Influence of Model Structure on Solution Effort in Dynamic Electrical Networks

Page 78

1. Introduction

Page 79

2. Mathematical Models of a Resistive-Inductive Network According to the Loop-Current and Loop-Flux Methods

2.1 Structure of the Models

Page 80

2.2 Properties of the Models

2.21 Eigenvalues of the Differential Equation System

Page 81

2.22 Types of Equation Systems to be Solved

2.23 Possibilities for Determining the Inductive Voltages

Page 82

Page 83

3. Examples

3.0 Magnetic Characteristics

3.1 Example 1: Single-Phase Nonlinear Choke

3.11 Description of the Network

3.12 Comparison of the Loop-Current and Loop-Flux Methods

Page 84

3.2 Example 2: Three-Phase Nonlinear Choke

3.21 Description of the Network

Page 85

3.22 Comparison of the Loop-Current and Loop-Flux Methods

References

Page 86

Page 87

Page 88

ABW \ RI	0.2	0.4	0.6	0.8	1.0	2.0	3.0	4.0
2	1	1	1	1	1	1	1	1
3	7	9	10	11	11	11	10	8
4	11	16	19	22	20	18	16	13
5	12	20	28	35	34	32	23	18
6	16	27	39	42	52	39	27	22
7	—	29	5x	64	69	58	34	26