SIMPAC(ID:169/sim025)Fixed step simulation languagefor SIMulation PACkage Mike Lackner, SDC, Santa Monica 1960 Early simulation language with fixed time steps. Places Related languages
References: This paper is presented in three parts: an introductory discussion on digital (computer) simulation; a description of SIMPAC (simulation package); and an outline of MUSE, a set of simulation systems based upon general modeling concepts. Basically, SIMPAC is a set of tools, e.g., macro-instructions and associated algorithms, compiler and execution programs, which will enable the analyst to develop a model of the system in question. It appears to be another "attempt" at the construction of a general-purpose simulation language. The reviewer must say "attempt" in that it is not clear from the paper how successful the model has been. The author relates how a business system was implemented with the first version of SIMPAC (not the version described in the paper) and offers an example of how to use SIMPAC. The reviewer feels that the reporting of such schemes should be accomplished by statements of its adequacy and whether or not SIMPAC has indeed simplified the generation of simulation models. In this case, it is rather difficult to determine in that it appears as if SIMPAC I was an outgrowth (maybe an afterthought) of the desire to develop a business system model. One has the feeling of an urge to rush into print (or make a meeting) with basic thoughts and not much else. The same must be said of MUSE. The author, like many others, wraps his concepts in the cloak of respectability supplied by much definition and notation. He is able to offer us "a loose description of the first, and basic system . . . S1 (which) is predicated on a simplified interpretation of the Weltan~cht, and is inchoate at this writing." S. I. Glass, Washington, D. C. in ACM Computing Reviews 3(06) November-December 1962 view details in ACM Computing Reviews 3(06) November-December 1962 view details -A model of the system which is intelligible to the student of the system while compatible with the limitations of the computer. -Translation of the model to computer code. -Movement of the model through time. -Recording the performance of the model. SIMPAC, a "simulation package," incorporates coherent techniques and devices for the accomplishment of these objectives: modeling concepts for building a computer-compatible model, a vocabulary for encoding the model, a computer program for moving the model through time and recording its performance, and an output presentation program. A model of a hypothetical business system has been implemented with the first version of SIMPAC for the purpose of studying management controls in a complex system. This paper discusses digital simulation and SIMPAC and introduces modeling concepts which may lead to a set of simulation systems, called 'Muse', which would assemble models of varying complexity from descriptive statements and analyze the models prior to simulation. Extract: Introduction Introduction The fundamental attraction of digital simulation to the analyst or designer of systems is that a dynamic model can be constructed whose behavior can he studied. Using traditional techniques of analysis, particular questions are asked and particular answers obtained. With a simulation model, a student of a system may see much more than end results of individual calculations. He may examine how things happen as well as what things happen. Problems too difficult to phrase with traditional techniques may be studied with simulation. Simple relationships may be assembled to form a model which defies traditional statement but which runs on a computer and produces a time series for every variable. Analysis and design have traditionally involved the use of models, such as architects plans and specifications. The first dynamic models were physical analogs; e.g., scale models. A simulation model must represent a dynamic situation. Actions as well as entities must be represented. Digital computers permit the implementation of dynamic, logical models; system models may be made machine interpretable and may be implemented by machines. A simulation model for a digital computer may represent entities with descriptive data and actions with algorithms -- series of individual arithmetic-logical operations upon the data. A computer is well suited for the elaborate bookkeeping involved in moving such models through time. Modeling and implementation have been time consuming and expensive. Several attempts have been and are being made to reduce time and expense of implementation while preserving the inherent versatility of the digital computer. This paper does not survey or evaluate these various simulation schemes but describes one such effort at System Development Corporation. The paper is in three parts; an introductory discussion of digital simulation; second, a description of SIMPAC, short for 'simulation package'; third, an outline of Muse, a set of simulation systems based upon general modeling concepts. Extract: Background Background For the purpose of studying management controls in a complex system, the Management Control Systems Project at System Development Corporation hypothesized and described an entire business system, a manufacturing concern, to be simulated on a digital computer. The Mark I business system model has been implemented with the first version of SIMPAC, which was developed and checked out in parallel with the construction of the first modules of the model. The problem of implementing a model of such a total system on a digital computer required the development of a method of system analysis capable of rendering the system in a form translatable to a digital simulation model and a means of implementing the model. These tools comprise a "simulation package" called SIMPAC. This first version of 'SIMPAC' differs in several respects from the version described in this paper. Most important of these differences is the treatment of what was called "reference information" in the earlier version. It was recognized then that all information in the model could be handled as "object information," i.e., contained in specific transient records, but it was felt that a network might become needlessly intricate if all information were so exchanged. (Some savings in running time were also involved. ) Therefore, a means of aggregating information exchange operations had been provided in the form of "reference files. " Elimination of these reference files does away with several compromises and clarifies the operation of the system by requiring more explicit treatment of certain model components, such ns activity performers, previously handled by the reference files. The implementation of a digital simulation study is typically achieved in four sequential steps: Model construction, Model translation to computer code, Model performance, Performance evaluation. SIMPAC offers techniques and devices for the accomplishment of these objectives. They are described in the order in which they occur: modeling concepts; a vocabulary for encoding the model; a computer program for moving the model through time; and an output presentation program. Extract: Modeling Concepts Modeling Concepts The modeling concepts are derived from the problem of representing an aggregation of diverse activities as an information-processing system -- something which can he implemented with a digital computer. These observations can be made of many systems: - The system contains recurring activities which interact through exchange of information. - Activities are performed at different times or at different rates. - Buffers capable of storing information exist between activities. - A discrete performance of an activity takes place when: a) people or machines capable of performing the activity are assigned it, and b) information required for performance is accessible. - The duration of a discrete performance of an activity is a function of the quality and quantity of people and machines performing. - Records carrying transient information generated in the discrete performances of activities tend to form queues between activities performed at different times or at different rates. - There are more activities performed than there are people or machines who perform them. The controls to which these systems are sensitive are: Queue discipline: dictation of the order of transient records in queues, and the mode of selecting them; Resource allocation: assignment of activity performers to various activities they can perform; and Information routine: specification of the source of information input to an activity and the destination of output information. The basic modeling concepts are those of activity, activity performer, transient information record, and queue. A caricature of the system drawn upon these concepts places the system an information-processing context. Activities be defined as series of arithmetic-logical operations--algorithms. Activity performers may identified by quantitative and logical descriptors, and transient information records contain like descriptors by definition. Such a model is relatable to the phenomena under study and conveniently translated to computer code. In conducting this type of modeling: - Potential queues are identified, - Transient information in the system is identified, - Activities are separated from the people or machines who perform them, - Control activity is identified and characterized, - People and machines are measured in terms of their ability to perform activities. An activity is performed if - Activity performers are assigned it. These are the people or machines who can perform the activity. They are assigned by other activities (which are performed if .... etc.). - The transient information records required for its performance are in its input buffers. These records represent the information or physical entities required for performance. Activities in the system may exert direct or indirect control over other activities or merely exchange information with them. They may assign activity performers to and from other activities, modify the queue disciplines used by other activities when securing or storing transient information, or they may direct the flow of information by specifying input and output buffers for other activities. Extract: SIMPAC's Weltansicht SIMPAC is predicated upon a Weltansicht which recognizes systems as complexes of transient information, queues formed in the system's buffers by transient information records, algorithms which generate, use and destroy this information, and performers of these algorithms. This is a fairly general "world view" and, as a result, SIMPAC is a fairly general simulation tool. Muse is the name given to the project of developing a simulation capability more general and more efficient than SIMPAC. The name is appropriate in that simulation is a blend of art and science, and several - if not nine - simulation systems may be developed. These systems will be developed with more regard for pure theoretical considerations than was SIMPAC, whose development was greatly influenced by immediate, practical considerations. This is not to say that practical considerations will be ignored; they will be weighed, but the practical considerations will be tomorrow's rather than today's. Before introducing the special "world view" upon which Muse is based, several terms which have been used throughout this paper are defined. 'Model' - 'A representation of an aggregate of phenomena' 'Symbol' - 'A representation of a phenomenon' 'Simulation' - 'Dynamic representation of dynamic phenomena' 'System' - 'A body of phenomena' 'Object system' - 'A system to be modeled; the system under study' A symbol is a representation of a unity, a whole. A model is a representation of an entirety, an aggregate whole. A simulation model is a representation in time of an aggregate whole, a representation of a dynamic, aggregate whole. Mere aggregations of phenomena need not be systems but may he modeled. An aggregation of phenomena is a system if it forms an organic whole. Weltansicht: there are things, and every thing may be from time to time, in several logical states. A logical situation is a particular pattern of certain things in certain states. Multiple occurrences of similar things in similar states may give rise to multiple occurrences of similar logical patterns and thus multiplicities of similar logical situations. Certain logical situations invite the exertion of forces which affect those things in the logical situations, destroying the situations. Thus things are created, destroyed, and placed in different states. The following definitions are adopted from this "world view." 'logical situation' - 'A logical pattern formed of certain things in certain states' 'Total logical situation' - 'The logical pattern formed of all things' 'Event' - 'A change in a logical situation' 'Evenement' - 'A change in total logical situation' 'Unstable logical situation' - 'A logical situation which invites the exertion of a force' *Stable logical situation' - 'A logical situation which does not invite the exertion of a force' This definition of 'evenement' does not admit of simultaneous evenements. There may be simultaneous events, but they produce but one change in total logical situation. 'F' - 'The class of forces' 'Q' - 'The class of logical situations' 'To - 'The class of things' Several simulation systems will be developed, based upon these concepts. In all models constructed within these systems, things and thing/ states are represented by symbols, forces are represented by algorithms, and logical situations are represented by patterns of thing/state symbols. in [AFIPS JCC 21] Proceedings of the 1962 Spring Joint Computer Conference in San Francisco, Ca. SJCC 1962 view details in ACM Computing Reviews 4(04) July-August 1963 view details in ACM Computing Reviews 4(04) July-August 1963 view details in ACM Computing Reviews 4(04) July-August 1963 view details in ACM Computing Reviews 6(06) November-December 1965 view details in [ACM] CACM 9(10) October 1966 view details [321 programming languages with indication of the computer manufacturers, on whose machinery the appropriate languages are used to know. Register of the 74 computer companies; Sequence of the programming languages after the number of manufacturing firms, on whose plants the language is implemented; Sequence of the manufacturing firms after the number of used programming languages.] in [ACM] CACM 9(10) October 1966 view details in Computers & Automation 21(6B), 30 Aug 1972 view details The exact number of all the programming languages still in use, and those which are no longer used, is unknown. Zemanek calls the abundance of programming languages and their many dialects a "language Babel". When a new programming language is developed, only its name is known at first and it takes a while before publications about it appear. For some languages, the only relevant literature stays inside the individual companies; some are reported on in papers and magazines; and only a few, such as ALGOL, BASIC, COBOL, FORTRAN, and PL/1, become known to a wider public through various text- and handbooks. The situation surrounding the application of these languages in many computer centers is a similar one. There are differing opinions on the concept "programming languages". What is called a programming language by some may be termed a program, a processor, or a generator by others. Since there are no sharp borderlines in the field of programming languages, works were considered here which deal with machine languages, assemblers, autocoders, syntax and compilers, processors and generators, as well as with general higher programming languages. The bibliography contains some 2,700 titles of books, magazines and essays for around 300 programming languages. However, as shown by the "Overview of Existing Programming Languages", there are more than 300 such languages. The "Overview" lists a total of 676 programming languages, but this is certainly incomplete. One author ' has already announced the "next 700 programming languages"; it is to be hoped the many users may be spared such a great variety for reasons of compatibility. The graphic representations (illustrations 1 & 2) show the development and proportion of the most widely-used programming languages, as measured by the number of publications listed here and by the number of computer manufacturers and software firms who have implemented the language in question. The illustrations show FORTRAN to be in the lead at the present time. PL/1 is advancing rapidly, although PL/1 compilers are not yet seen very often outside of IBM. Some experts believe PL/1 will replace even the widely-used languages such as FORTRAN, COBOL, and ALGOL.4) If this does occur, it will surely take some time - as shown by the chronological diagram (illustration 2) . It would be desirable from the user's point of view to reduce this language confusion down to the most advantageous languages. Those languages still maintained should incorporate the special facets and advantages of the otherwise superfluous languages. Obviously such demands are not in the interests of computer production firms, especially when one considers that a FORTRAN program can be executed on nearly all third-generation computers. The titles in this bibliography are organized alphabetically according to programming language, and within a language chronologically and again alphabetically within a given year. Preceding the first programming language in the alphabet, literature is listed on several languages, as are general papers on programming languages and on the theory of formal languages (AAA). As far as possible, the most of titles are based on autopsy. However, the bibliographical description of sone titles will not satisfy bibliography-documentation demands, since they are based on inaccurate information in various sources. Translation titles whose original titles could not be found through bibliographical research were not included. ' In view of the fact that nany libraries do not have the quoted papers, all magazine essays should have been listed with the volume, the year, issue number and the complete number of pages (e.g. pp. 721-783), so that interlibrary loans could take place with fast reader service. Unfortunately, these data were not always found. It is hoped that this bibliography will help the electronic data processing expert, and those who wish to select the appropriate programming language from the many available, to find a way through the language Babel. We wish to offer special thanks to Mr. Klaus G. Saur and the staff of Verlag Dokumentation for their publishing work. Graz / Austria, May, 1973 in Computers & Automation 21(6B), 30 Aug 1972 view details in [ACM SIGPLAN] SIGPLAN Notices 28(03) March 1993 The second ACM SIGPLAN conference on History of programming languages (HOPL II) view details in The 27th Winter Simulation Conference 3-6 December 1995 Hyatt Regency Crystal City, Arlington, VA view details |