12th WSEAS International Conference on COMPUTERS, Heraklion, Greece, July 23-25, 2008
Super-Object-Oriented Programming and Simulation EUGENE KINDLER Department of Informatics and Computers University of Ostrava 30. dubna 22, CZ – 701 03 Ostrava 1 CZECH REPUBLIC
[email protected] Abstract: The progress in computer simulation tends to simulate complex systems governed by “internal models”, i.e. sophisticated activities of computing technique in real time flow. Independently of that, computer simulation needs the object-oriented programming and the agent-based paradigm for constructing “external models” of complex systems that are being designed. Thus the progress tends to use models with other models nested, and knowledge systems with other knowledge systems nested. The paper is oriented to survey the findings, needs, obstacles, solutions and existing applications, namely by means of so called super-object-oriented programming. Key-Words: - Simulation, Nested models, Object-oriented programming, Nested systems, Nested agents gramming language called SIMULA (formerly SIMULA 67, because it was presented to the world professional community in 1967 [1]). Many years later, the OOP equipment was introduced into other (more popular) languages like SmallTalk, C and Pascal, which had begun their existence without that equipment). The essence of OOP consists in the following ways of knowledge representation. Concepts are represented by classes while running programs (among other simulation models) are performed by “instances” of the classes (an instance is a model of a physical thing carrying the essence of the concept/class). The classes are structures composed of name (of the class), attributes (data that are meaningful for every instance of the class) and methods (algorithms that every substance of the class can perform when it becomes a “message” to perform the method). The classes can be specialized to “subclasses” that represent concepts with greater contents and lesser extents (numbers of instances). The specializing consists by adding new attributes and new methods. An essential component of OOP is a possible “virtuality” of methods – a method can be introduced as “virtual” for a class in sense that its contents (algorithm) can be defined in its subclasses (possibly in different ways for different subclasses). Specialization can be iterated (a subclass can be specialized, too, etc.). A domain D of systems may be viewed as a base of a scientific discipline. In case OOP is applied to represent concepts that characterize the domain, the results form a set L of classes (and possibly of their subclasses, too), which can be viewed as certain formal theory of the mentioned discipline. The process of forming L is sometimes called domain analysis [2]. If the names of the classes and their methods and attributes are carefully chosen they enable using L as a language similar to that
1 Introduction 1.1 Object-oriented Programming and Simulation Computer simulation is used for studying complex systems. The complexity of systems implies the complexity of their simulation models. In order to facilitate their construction, debugging and modification, simulation languages were developed. Their essence is to eliminate the transformation of an exact description of the simulated system into computer modeling program. Instead of troublesome programming of something like a programalgorithm governing the computer during simulation, the simulation language user describes the structure and dynamics of the simulated system and the description is automatically converted into a machine program that the computer can perform. The conversion is generally made by the language compiler. There is a lot of sorts of systems on that one demands to be simulated and accordingly there are many simulation languages, each of which being oriented to a certain “domain” (sort of systems) and demanding its own compiler. The number of domains increases as new system domains arise. This process is stimulated not only by application of simulation in new branches but by interdisciplinary views on many objects and – in the last years – by demand to simulate “intelligent” systems. The growing number of the domains needs new simulation languages and that is projected into demands for new compilers. But there are no sufficient resources to do it. Already in the middle of the sixties of the last century, the obstacles were solved by inventing a programming paradigm, later called object-oriented programming (shortly OOP). The full equipment for OOP (and much other – see part 3 and especially 3.4) is in a pro-
ISSN: 1790-5109
1049
ISBN: 978-960-6766-85-5
12th WSEAS International Conference on COMPUTERS, Heraklion, Greece, July 23-25, 2008
used in dialogues among the specialists interested in the objects of D and therefore the dialog between such a specialist and a computer can be similar as a dialog between two humans-specialists. If D is oriented to a certain (infinite) set Q of dynamic systems, L can be used as a simulation language oriented to models of the systems belonging to Q. So the problem of a compiler of a simulation language applicable for implementing the models of the systems belonging to Q is solved – instead of programming the compiler one defines L (which is far simpler).
M
E1
C
m E2
E5
e1
e3
E3
e2 e4
e5
1.2 Nesting Models
e6
E6
Fig. 1
Simulation is sometimes applied to recognize properties of systems that really (physically) exist (or existed) and gave results. But the largest domain of the use of the simulation consists in foreseeing the future behavior of systems. Two branches of such an application exist: 1.2.1. The simulated system S is designed, it does not exist and its details are not known yet. Let A denotes what exists: it is a part of the human society together with the instruments for the design of S, among which there is a computer that serves to simulate possible variants of S. After having evaluated the data collected in some simulation experiments, A decides about its instantaneous and future steps (may be disregarding some variants, formulating new ones, etc.). 1.2.2. The simulation is used to manage a system B that exists and is operating; the computer carrying the simulation models is a component of B. The simulation models reflect what could happen in B in future as consequences of various possible decisions and B uses them to choose the instantaneous decision that would be optimum with regard to its own future. Let the simulation models of the variants of S figuring in 1.2.1 be called external models of S and let those figuring in 1.2.2 be called internal models of B. In case B contains active persons something as simulation models often exists in the minds of the persons, as they use to decide according to their imagining of some future consequences. Then B is an anticipatory system in a week sense, even if it has no a simulating computer. Nevertheless, in designing modern automated systems, the human imagining is transformed to computer simulation. Compared with other techniques, simulation needs more computing time and complex models. Because of that, simulation should be used only when the other techniques fail. Suppose a system S is being designed and the designers are sure that certain decisions in its operation will be necessarily based on internal simulation models; then it is reasonable to include that fact into its external model. If it were simplified so that the mentioned decisions would be represented by some much simpler rules, then two logical consequences follow: (i) either the
ISSN: 1790-5109
E4
information generated by the external model is be good and reliable, (ii) or the information generated by the external model informs erroneously about the system when it would be realized in future. If (i) holds, the opinion about the exigency of the internal simulation models was false and S can be constructed without them. Let the following considerations be concentrated on case (ii). If we demand the external model to give reliable information we have to map the simulating element (or elements) existing in it and handling the internal models in such details that those internal models are nested into the external model. The basic structure is outlined in Fig. 1, where the whole figure represents the external model M with its elements E1, …, E13 and C. While Ei represent some “habitual” components of the simulated system, C represents the simulating computer that contains the internal model m with its elements e1, …, e6.
2 Problemes with Implementation 2.1 Several Time Flows When one has to construct the external model M he must include the internal model m into it, as that corresponds to the reality (m exists in the same simulated part of the world as the element c carrying it, and as the other components represented by the elements outlined as E1, …, E13) and namely to the communication when c has to create m or to tailor it to reflect the present state of its environment. M should have use of the software that reflects the scheduling within the framework of the Newtonian time flow T, while m should have use of the same software but related to another time flow t. Both the time flows have almost the same properties, but they have to be interpreted as two different phenomena. As an example the following statement can serve: during the time interval the internal model computers what could be expected to come during the time interval . T1 and T2 belong to the time flow
1050
ISBN: 978-960-6766-85-5
12th WSEAS International Conference on COMPUTERS, Heraklion, Greece, July 23-25, 2008
T, t1 and t2 belong to the time flow t and in a habitual situation the difference t2–t1 could be much greater than T2–T1. As it was already mentioned at the beginning of this paper, the simulation programming languages serve to facilitate the construction of simulation models. Many of them (namely those oriented to discrete event systems) have tools for ordering the events rooting in different (and may be more or less mutually independent) processes into one time flow and to interpret them in the same order in the simulation model run. It is necessary to map the causality existing in the simulated system, into the causality in the computing model. Unfortunately, every simulation language supposes only one time flow existing in the simulated system and reflected in the simulation model. For the purpose when a simulation model is nested in another one, the simulation programming languages fail.
error that takes an element of one model and assigns it a name introduced for (similar) elements in another model. In case of event scheduling, such an error could be made by scheduling a process belonging to a certain model A immediately after a process belonging to another model B (let the reader consider what could happen in case A is the internal model and B is the external one, or vice versa). Beside the fact that transplantation has no rational interpretation in the real world, its main danger consists in a possibility to “wild run” of the participating models that commix and lead to an error (often an internal computer error as nonexistent address etc.), the first reason of which cannot be determined after millions of computer wild run operations. Nonetheless, the obstacles with time flow apparatus present only a basis that can be simply generalized. The external model and the internal one nested in it concern the same thing and although they can differ in details (for example, in many cases the internal model contains no model nested in it) the user would like to describe both the model by the same terms – statements concerning the time scheduling represent only a small kernel. A robust solution of the problems related to the “homonymy” of terms used in different models is desirable.
2.2 Homonymy of Names As the way out from the mentioned problem, OOP seems to help. Namely, it could seem that the solution consists in declaring the operations concerning the time flow for each of the models. Unfortunately, almost every object-oriented tool fails, tool. The main reason consists in the users’ evident demand to use the same terms (names of classes, their instances, methods and attributes) in any case of scheduling events. In other words, any user would refuse as unacceptable the demand that for formulating the internal model he should use terms for the scheduling events different from those offered in case of the external one. The reason of those demands consists that for many tools for OOP – and namely for the most popular ones like C++ and newer versions of Pascal and SmallTalk – no local classes can exist: every class is declared for the whole program or program module and declare two classes with the same names would lead to the name conflicts, which the language processor refuses. The OOP tools represent certain formal systems the complexity of which could be compared with that of famous mathematical theories; accordingly to that, one could expect that even the OOP tools mentioned above would offer some solution of the mentioned problems in a more or less distant future (the hope can remain before no exact proof of the impossibility is derived). Nevertheless, even some sophistical experiments for the solution fail, namely because of other reasons. Let us present an example. One could define a class of time flows independently of any simulation model and then assign different instances of that class to different simulation experiments. In principle, that would be possible but a danger called transplantation arise with it, which is a programming
ISSN: 1790-5109
3 Principles of Solution 3.1 Nested Classes The first step in solution consists in using classes nested in other classes, i.e. in a certain enlarging of class concept: while in the “traditional” understanding to OOP the concept of class is understood as a structure of a name, attributes and methods, the “super” understanding of OOP allows a class to be considered as a structure of a name, attributes, methods and classes. Such a class is called main class and the classes declared as components of its structure are called nested classes (or local classes, see section 3.3). Similarly, as any instance of a class has its own attributes and its proper considering its methods, the main class has its own considering its nested classes. The pragmatics of the main class is that it represents a world viewing (or a language or a formal system) using the nested classes as notions. A simple example is the main class representing planar geometry so that its attributes may be components of its coordinate system and its nested classes reflect the notions of point, line, circle, triangle etc. In the simplest approach, the solution of the two time flows problem can be solved so that the tools (classes, methods and names) enabling a suitable scheduling of the events occurring in the external model are introduced among the other classes used in this model, while the
1051
ISBN: 978-960-6766-85-5
12th WSEAS International Conference on COMPUTERS, Heraklion, Greece, July 23-25, 2008
same tools used in the internal model are introduced among the attributes and methods of the class of the simulating computers. Both the introducing texts can be identical and so they enable the users to use the same terms when they express any information concerning the scheduling in time, independently of the model that it concerns. Note that the same principle can be applied for satisfying the homonymy of other terms, namely those used for description of both the external and internal models. An illustration can be seen in Fig. 2, which represents the same situation as in Fig. 1 but the main classes are added: TIME is the main class offered for handling the time axis, DOMAIN is its specialization oriented for viewing certain system S, SYSTEM is its specialization tailored to the description of the external model of S and system is the specialization of DOMAIN tailored for the description of the internal model of S. The broad arrows represent the specializations and the clusters of the other arrows represent applications of the main classes, among other constructing instances of classes nested in the corresponding main classes. The applied main classes can be also interpreted as the concept bases through that the given anticipatory system views the anticipation. When a (part of) human society A demands to foresee the optimal variant of the system it designs, it formulates certain principles represented as knowledge contents of the applied main class C1 and according to that it constructs the external models. When A supposes the designed system to be automatically managed by a computer with help of an internal model, the main class C2 serving for its construction represents the notions that A supposes to be applied during the managing. Evidently C1 and C2 have a lot of common components; they can be profitably collected in a superclass G of both C1 and C2, which should be specializations of it. In Fig. 2, G corresponds to DOMAIN, C1 to SYSTEM and C2 to system. Evidently each of the classes C1 and C2 has to be out of the model which is SYSTEM
DOMAIN
constructed with its help; so C1 should be at the level of simulation study (an ordered sequence of simulation experiments using the external models) and C2 at the level above the internal model m, i.e. as a component of the contents of the “computer” that carries m. It suitably corresponds to the real relations between the concerned simulation models and the knowledge systems used in their implementation. In Fig. 2, the level of simulation study is outlined as a rectangle in dotted line.
3.2 Life Rules The first discrete event simulation language GPSS [3] was not object-oriented; it allowed its users to introduce classes as sets of similar data structures, i.e. no subclasses, no methods and no virtuality. Number of instances of any class had to be introduced with the class itself. Nevertheless GPSS introduced something that could be called life rules of any instance of the class. Their form was similar to simple algorithms, i.e. they were composed of components (statements) like assignments, branchings and cycles and when an instance of a given class was generated it started performing these life rules; that reflected the proper “life” of the instance. But – contrary to e.g. subprograms – so called scheduling statements could occur among the life rules, which interrupted performing the life of an instance in account to performing certain phases of the lives of other instances. In the simulation model, the use of scheduling statements could reflect contemporarily existing lives of several elements of the simulated system – namely when one element’s life is waiting the lives of other elements can go on and even influence satisfying the condition (e. g. when a life of an element E is performing a scheduling statement telling “wait in a queue until having turn”, other elements can perform something according to their own life rules). Although GPSS was very popular until the end of the twenties century in USA [4] and – in certain dialects like SIMDIS [5] or SIAS [6] – in Europe, too, the life rules were introduced into other simulation languages in a form closer to the general algorithmic usages, namely to those linked with Algol 60 – the first language of that sort was SOL [7] and then SLANG [8]. A discrete event simulation language called SIMULA [9] was also of this type and the ALGOL algorithmic tools were built into the object-oriented language of the same name SIMULA mentioned in section 1.1 [1], [10], [11]. Except BETA [12], MODSIM [13] and NEDIS [14], no other OOP language offers life rules. Note that the life rules give the instances of classes aspects of agents. A class that is separately compiled may represent autonomous agents. Classes nested in a main class may be considered as agents with social behavior and the main class may be viewed as a class of
TIME
M C
E1
m
E3 E5
system e1
e3 E4 E2
e4 e5
E6
e2
e6
Fig. 2
ISSN: 1790-5109
1052
ISBN: 978-960-6766-85-5
12th WSEAS International Conference on COMPUTERS, Heraklion, Greece, July 23-25, 2008
individual systems in that the sociality of agents are meaningful. BETA and SIMULA offer tools called sequencing statements that enable switching among the instance lives, which is independent of time flow; these tools make the class instances agents that exist independently of simulation. In the mentioned languages, the scheduling statements are viewed as methods defined with use of the sequencing statements.
(b) In case class C is a main class, then – when J‘s life is being in B – J can be viewed as an image of a more professional being that has use of a “theory”, “world viewing” or “language” C. J can even specialize C in order to “tailor” it for its “private” use. (c) In case J leaves B it has no more profit of its local entities (including C); that applies also when the J‘s life returns to B; in that case J handles new local entities (i.e. those of a new instance of block B), which have no relation to those of the previous (left) instance. But before of the previous leaving of B, J can assign some information (that obtained during its phase inside B) to entities that are not local to B and then, e.g. during the next “stay” in B, it can use them. (d) In case another instance K of the same class as J enters B the entities local in B are interpreted as completely different from those handled by J. It holds for the classes local in B, too.
3.3 Blocks Already in 1960, complete apparatus of blocks was introduced in the definition of ALGOL 60 [15]. Block (exactly: textual block) is a part of a description of dynamics (in the present paper: of life rules), the context of which is similar as that of other rules (assignment, cycles,…). It is a sequence s of such rules and has local entities that are accessible only for the members of s (ALGOL 60 supposed the local entities being variables and procedures). When the life of an instance enters a block an “instance” of the block is generated as a structure composed of the entities introduced as local in the textual block. If the life rules of s have to operate with the local entities they handle those of the given structure. In general, several instances of the same (textual) block can exist at the same moment – in ALGOL 60 it was possible, for example when a procedure containing such a block was called recursively, while in the simulation it can happen e.g. when several instances of the same class enter the same block of the life rules. An important aspect of ALGOL 60 block consisted in block nesting – among the components of s forming a textual block B1, another textual block B2 can occur with its own local entities. Moreover, in case B2 has a local entity identified with the same name as a local entity introduced for B1, then inside B2 the name refers to the entity local to B2 (and – evidently – the same name occurring in B1 refers to the entity local in B1, because the entity local in B2 cannot be taken into account outside B2). With the exception of both SIMULA languages, the other simulation languages mentioned above did not allow blocks as components of the life rules even in case they adapted many other tools of ALGOL 60. But the object-oriented SIMULA continued further: it allowed introducing classes among the local entities of a block. That has several consequences: (a) When the life of an instance J enters into a block B where a class C is introduced as local, J can be viewed as an image of an element that enters a “professional phase” of its life, namely using a concept C and its possible “material” representations (instances of C) into its own thinking.
ISSN: 1790-5109
3.4 Synthesis – Super OOP At the present moment, we can see that in the objectoriented SIMULA, class is an abstract definition of an entity composed of attributes, methods and life rules and block is an abstract definition of similar entities (only instead of attributes one speaks on local variables and instead of methods one speaks on procedures, routines or subprograms). The difference between class and block consists in three possibilities for classes that do not exist for blocks: class can be specialized, class has its name and the instances of classes can get names and using the names their “local” entities can be applied outside the class (it is called remote identifying and in SIMULA expressed by “dot notation” – e.g. if x is a name of an instance which can perform a method called m, then the x.m is a “message” sent to x and demanding it to perform m). Another difference is that an instance of a block is generated when the life rules enter it, while the instance of a class is generated by a special expression called generator (in SIMULA written as new C where C is the name of the class). Note that procedure (method) is a notion existing between class and block: procedures have names and with use of them their instances can be generated, but these instances cannot get names. Thus the concept of main class is very similar to that of block with local classes and a very general way of nesting blocks and classes (and its combination) is offered to the users. The object orientation enlarged by life rules, main classes and block nesting is sometime called Super-Object-Oriented Programming (abbr. SOOP [16], [17]). It is an excellent tool for implementing and handling simulation models of systems containing simulating elements, as it will be described in the next section.
1053
ISBN: 978-960-6766-85-5
12th WSEAS International Conference on COMPUTERS, Heraklion, Greece, July 23-25, 2008
SYSTEM
DOMAIN
The internal model is simulation one while the use of the external one is different from simulation (the external model may have no relation to the flow of any time). It is often a case of a simulation study (see above) that is controlled by rules so complex that one could describe them only by means of classes introduced for the whole simulation study. Although simulation study is traditionally considered as a controlled sequence of simulation experiments ([18] – only after one simulation experiment of a study is finished the following experiment can start), the mentioned approach enabled to organize a software that enabled efficient system optimizing using contemporarily existing and mutually switching simulation models of different variants of the optimized system (the software has use of SIMULA sequencing statements [19], [20]). The external model is a simulation one, while the internal one not. That is the case of the simulation of the systems that are internally controlled by rules that are so complex that it is suitable to describe them as models of certain complex systems. A rather attractive case is when the complex controlling rules can be imagined as based on a certain fictitious dynamic system F. At the end of [21] examples of such a transformation were presented. In such a case, the model of F can be built into the external model as an ordinary internal simulation model. The only difference is that F uses to be rather different from the external simulation model, and – consequently – that the knowledge system for the description of the model of F may very differ from that serving for the constructing of the external model. Nevertheless, there is something common for both the systems, among other the rules for Newtonian time flow; there are surely other common aspects because even the fictitious system F has to be in a certain relation to the problems of the system simulated by the external model. An illustration is in Fig. 4, which
TIME
M
system E1
C
E3 E5 E4
m e1 e2 e3 e4 e5
e6
E6
E2
Fig. 3
4 Completion 4.1 Switching models Let us observe Fig. 2. Its main frame, represented in the dotted line, can be interpreted as a block in that the main classes TIME, DOMAIN and TIME are introduced. It is suitable for experimenting in the simulation study that (according to the international simulation terminology standard [18]) is defined as sequence of simulation experiments, i.e. of internally independent simulation models. It would seem that no block is required to enclose the internal simulation model m and, therefore, that Fig. 2 is prefect. In very special cases, namely in case we are sure that the computer like C will only handle one model m, it is so, but – in general – a computer can be applied for many tasks, among other for many decisions supported by their own simulation models and even for performing studies with very different simulation experiments (a striking example is presented in section 5.4). So it is better to enclose every explicit description of an internal model into a proper block. In case of one description, Fig. 2 should be modified in the way presented in Fig. 3; the internal model should be nested into a special block in which the knowledge system used for its description is included, too. In case the computer should simulate a variant described with use of another knowledge system, the life rules of the computer directed its life to enter another block (in Fig. 3, the smaller dotted line rectangle and its inward would be replaced by a dotted line rectangle with a different inward).
SYSTEM
TIME
M
E4
fictitious C
m
E1 E5
4.2 Generalization
E3
What was derived in the previous sections for simulation of systems containing simulating elements can be generalized for non simulation models. In principle, there are three sorts of such a generalization.
e1
e3
e2
f2
f1
e4 e6
e5
E2 E6
ISSN: 1790-5109
DOMAIN
f3
f4
E7
Fig. 4
1054
ISBN: 978-960-6766-85-5
12th WSEAS International Conference on COMPUTERS, Heraklion, Greece, July 23-25, 2008
is derived from Fig. 3 and represents a state derived from that depicted in Fig. 3: if we assume that in the internal model m, ei is an image of Ei that reflects an element of the simulated system in the external model, then m does not reflect element E7 but manipulates with elements f1, …, f4 that have no analogy in the external model (and therefore they probably do not map any “true” component of the simulated system). The use of simulation models of fictitious systems is called pseudosimulation or fictitious simulation. The nested simulation where the internal model concerns the same object as the external one is called reflective simulation [23]. The third combination consists in a pair of two nonsimulation models. We did not meet any application of such a model nesting but one can hope that e.g. in computer graphics and animation it will have a wide field of activity (moving images of drawing elements, mowing displays with animated scenes etc.). One could think on other cases, namely of more than two models. For example, the systems simulated by the external model can have two computers so that one of them contributes to reflective simulation and the other performs fictitious simulation. Or the internal model itself can reflect a system with a simulating computer so it becomes an external model into a “nested” substructure – in such a case there are three levels of simulation or modeling – that of the true external one, that of the internal one nesting in it and that of the model nested in the internal one (note that such technique was already implemented [24]). A certain attempt to classification was presented in [25] and [26].
to simulated time t2 which is a bit greater than t1, and repeat mutual exchanging of information followed by making a new variant for one of them. And so the session of the experts goes on. Every expert, who have to introduce a new variant, tries to make it so that it behaves better than the operated variants. In some phase (in general, when the variants are expected to have run a longer time in their steady states), the process is concluded and gives a suitable (optimal or suboptimal) variant. Evidently the session of experts needs no own (measurable) time and event scheduling in it. For switching the experts’ lives in the computer model M of the session S, only sequencing statements (see the end of 3.2) are necessary. Thus the model M figures as a non-simulation model of S so that certain elements of S are viewed as having their own simulation models. The described software was applied for optimizing in metallurgy, machinery and services (e.g. the number of foundry cranes, assembly machines and places for emergency stations – see e.g. [27], [28]) and in neurology of the brain [29].
5.2 Fictitious Simulation Models Nested in Simulation Models One of the first application concerned simulation of a production equipped with automated transport by induction guided carriages [30]. The carriages were considered in a certain sense intelligent, as they had to determine the shortest paths to their destinations. For the computing of the shortest path, simulation of a fictitious system of pulses propagating from the start place as long as some of them accesses the destination was applied (a method ascribed to Dijkstra and Lee [21]). Evidently the pulses are objects that do not belong to the production system, but they move in a skeleton of connections that are components of the production system. If we would like to map that structure by means of the schema presented in Fig. 4, we could say that E1, … E6 represent the connections that are for disposal in the external model, e1, …, e6 represent the same connections in the internal model, E7 represents a carriage and f1, …, f4 represent pulses (of course, the application contained much more elements of all mentioned sorts). Knowledge system DOMAIN contained classes of the connections and “inherited” tools for event scheduling from knowledge system TIME. In SYSTEM, the knowledge system DOMAIN was enriched by classes of the carriages while in fictitious, DOMAIN was enriched by classes of pulses. The mentioned technique of computing the shortest path appeared suitable for other cases but in them the nested models were combined with other ones. More details are in 5.4.
5 Existing Models and Applications 5.1 Simulation Models Nested in Non-Simulation Models The mentioned technique of using a non-simulation external model for controlling a simulation study in that several simulation experiments run in parallel as internal models can be based on the following idea. Let a systems is to be optimized. There is a session of several experts. Each of them expresses his own idea on the optimal variant and a computer, at which he starts to simulate it. All experts simulate their variants from the initial simulated time t0 until a certain simulated time t1 in that the simulated systems could enter their steady phase. Then they exchange information on the behavior of the variants; the variant with the worst behavior is refused, its author collects information on the parameters of the other variants, derives new parameters from them for a new variant and simulates it at his computer from t0 to t1. Then all experts proceed to simulate their variants
ISSN: 1790-5109
1055
ISBN: 978-960-6766-85-5
12th WSEAS International Conference on COMPUTERS, Heraklion, Greece, July 23-25, 2008
state. Some of them demand only one step of processing for any object, other demand more steps. In such a case, sometimes the ordering of the steps is fixed, sometimes the steps can be more or less interchanged. The conveyor is controlled by a computer. Frequently the following situation occurs: at time t an object X is at a certain place p1 and it is necessary to determine the state of place p2, which is intended to be the next key position of X; the state of p2 at t can be detected but the transport of X from p1 to p2 takes some time dt and until t+dt the state of p2 can change. In order to foresee that state at t+dt (and – sometime – the size of dt, too), at time t the computer detects states of all relevant places of the conveyor, prepares the initial state of its own simulation model of the conveyor and by simulation computes dt and the state of p2 at t+dt. In order to recognize how the described “intelligent” control of the conveyor (i.e. the decisions with regard for the future) can improve the throughput of the conveyor, the mentioned simulation models were nested in the (external) simulation models of the conveyor during its testing before installation. Other questions came together with controlling the conveyors in case of errors that blocked access to certain working areas; the questions were like “Is it possible to finish processing a current series of objects or is it better to stop the whole production/logistic process and immediately to repair the error?” and possibly like “What change of the technological program should be chosen in case the process is not immediately interrupted?”. Also for these questions one introduced simulation in order to support the quality of decisions, i.e. to compare the possible variants of the derived answers. And using a similar way, one solved the problem concerning the situation when the conveyor was rather occupied and a new object came to it with a demand to be served there: it could enter immediately with a risk to make one or more complete rounds along the main circle without being allowed to enter to a working area – in such a case it could wait out of the conveyor and thus not obstruct the other objects in their moves; but in case it will wait, when should in enter? Further information on this matter can be read e.g. in [32]-[34], where further references occur. The focus of the works on the nesting simulation models is Czech Republic. Nevertheless, the works concerning the conveyor were developed in collaboration with University of South Brittany in French Lorient. Also the works described as follows were developed in France, namely at the University of Blaise Pascal in ClermontFerrand. They concerned simulation of logistic systems, connected with FMS (flexible manufacturing systems) [35], [36]. A certain interest arose at the University of Genova/Savona.in Italy. Let us shortly characterize the work of its students.
5.3 Simulation Models Nested in Simulation Models Czech doctoral thesis [31] contains a description of a simulation of the future demographic development of a region situated at the North-east part of Czech Republic. The simulation model itself allows for certain consulting centers, where the citizens interested in moving into the region from its environment, or in changing place inside the region, or in leaving the region could get prognostic data about the future possibilities of being employed in a given manner, getting a flat of a certain category and sending children to demanded sorts of schools. The consulting centers should have computers and simulation models of the region, able to run and generate information for the customers of the centers. So the use of simulation in the centers would damage the original model of the region development. Therefore the simulation model derived and presented in [31] contains some internal simulation models and is prepared to accept other ones. The application just mentioned is a typical example of reflective simulation (see section 4.2). Other applications were oriented to circular conveyors serving as local transport tools in production enterprises. An example is in Fig. 5: the corner marked with an asterisk is the place P where the objects are put to the main (great) circle of the conveyor. Then the objects are transported to the right and further opposite the clock hand rotation so that they can return to place P, repeat the round etc., but the objective is to send every object to one of the 5 working areas, namely to that assigned to the object for to be processed at the central place S of its segment stopper. In such a case, if S is occupied and the place R before it is free the object can enter the segment and wait at R. If R is also occupied, the object must go on by the main circle and miss the given working area. After an object has just been processed it may wait at place V following the central place; it holds when the object could not immediately return to the main circle, because it would collide with an object coming along the main circle. In different applications, various scenarios exist and were simulated. Some of them assign the objects fixed working areas where they should be handled, some allow to choose from several working areas according to their
*
R S V
Fig. 5
ISSN: 1790-5109
1056
ISBN: 978-960-6766-85-5
12th WSEAS International Conference on COMPUTERS, Heraklion, Greece, July 23-25, 2008
The first idea about the nesting simulation models arose in 1993 in relation with concurrent engineering, where one models a large system of research teams, while some of those teams use their own models. Both the sorts of the models could be simulation ones [37], but their synthesis into an external model with nested internal ones was probably not yet applied. Nevertheless the idea itself stimulated interest of some concurrent engineering specialists who expressed their hope for the importance of reflective simulation [38]. Later the author developed the ideas to demonstration models of queuing systems with one or more dispatchers who manage the tellers in before the queues. From time to time, according to the length of the queues, such a dispatcher decides about closing or opening some tellers; but he tests the possible consequences of his decision, so that he simulates the near future of the whole system and – according to the data given by the simulation – he may modify his decision [39]. Later the models could be used to model “intelligence” in different sorts of decisions – e.g. the interaction of teacher and pupil or of two bureaucrats who do not communicate and in virtue of that decide one against the other, without being aware of that [40]. During their three months residency at Ostrava University, two Italian doctoral students managed principles of SOOP, implemented the mentioned models in a different way, and linked them to other PC software [41]. Another application was developed by the author of the publication [31] mentioned above: it was a model of public transport using busses and organized in a town of about 42,000 inhabitants, and its large environment. The model reflects the passengers able to plan their paths as combinations of several bus lines and optimizing their decisions by imagining their duration [42].
simulation models shown that such conflicts often cause deadlocks, then other ones and finally a complete freeze of the moving in the container yard. The solution consisted in testing the path by simulating what would happen if the path were applied. In case the simulation discovers a possible conflict the place of it is marked by a fictitious container and the shortest path is re-computed. Because of the fictitious container, it differs from the preceding one; it is tested by simulation whether it does not lead to a conflict and so on, until a secure path is discovered. Thus the external simulation model of the container yard reflects a computer that is a component of the yard and handles with two rather different simulation models that alternate during computing any path [44], [45]. One of the models concerns fictitious simulation while the other would make the nesting simulation reflective. Another mixed case was realized as demonstration software by a student of Charles University in Prague [25]. The simulated system is composed of two queuing systems S1 and S2, each of which is influenced by decisions of its own dispatcher that simulated the possible consequences of the decisions. Therefore the system was like a pair of the copies of the system with a dispatcher, described at this page on the left. Each of the dispatcher could simulate future behavior of both the systems. Nevertheless the systems behaved as competitors, each of them wishing to attract customers by offering better conditions (namely shorter waiting in queues); but better service needs higher expenses and both the systems tried to respect a certain balance between the services and expanses for them. Essential is that the dispatcher of one of the systems was interpreted as able to simulate not only possible behavior of both the systems but also the simulation of the adversary’s dispatcher. Therefore the described external model M contains two internal models m1 and m2 nested in it but one of them – suppose m1 – has another model m nested
5.4 Mixed Cases During 1995-2000, two projects supported by the European Commission and oriented for IT-assisted modernizing freight sea harbors demanded to prepare generic software for simulation of container yards where groundmoving transport tools operate. The general routine for computing the shortest paths of the transport tools was based on the same psudosimulation following DijkstraLee method, as mentioned in 5.2 above (many details are in [43]). There is usually more than one ground-moving transport tool in a habitual container yard. In such a case a conflict caused by two of the transport tools. It can be caused either directly (a transport tool blocks the path of another transport tool) or indirectly (a transport tool puts a container onto a place where another transport tool should move in a near future. As the corridors among the column of stored containers use to be narrow, problems of diversions arise in such cases and experimenting with
ISSN: 1790-5109
6 Conclusion To the present time, possibilities of application of reflective simulation models of bed sectors of hospitals are under investigation. The necessary models are constructed and their consistent function was successfully tested [46] but the problems are in communication with the persons who would apply it. An opinion persists that deciding on the patient configuration in the bed wards does not need foreseeing supported by computer simulation. Thus one analyzes the formal aspects of those decisions in order to approach to questions that will be “ripe” for be supported by simulation [47]. Another starting work concerns designing certain information networks intended so that each of them will have a special computer C that will reconfigure the net-
1057
ISBN: 978-960-6766-85-5
12th WSEAS International Conference on COMPUTERS, Heraklion, Greece, July 23-25, 2008
Systems, Norwegian Computing Center, Oslo, 1st edition 1965, 5th edition 1967 [10] O.-J. Dahl, B. Myhrhaug and K. Nygaard, Common Base Language. Norwegian Computing Center, Oslo, 1st edition 1968, 4th edition 1984 [11] SIMULA Standard, Simula a.s., Oslo, 1989 [12] O. L.Madsen, B.Moeller-Pedersen and K. Nygaard, Object-Oriented Programming in the BETA Programming Language. Addison Wesley, Harlow – Reading – Menlo Park, 1993 [13] C. Herring, ModSim: A new object-oriented simulation language, SCS Multiconference on Object-Oriented Simulation. The Society for Computer Simulation, San Diego, 1990 [14] V. M. Glushkov et al., Programmnyje sredstva modelirovaniya nepreryvno-diskretnych sistem (Programming Tools for Modeling Continuous-Discrete systems – in Russian), Kiev, Naukova Dumka, 1975 [15] J. W. Backus, et al., Report on the Algorithmic Language ALGOL 60. Numerische Mathematik Vol. 2, No. 1, 1960, pp. 106-136 [16] H. E. Islo, SOOP Corner, ASU Newsletter, Vol. 22, No 2, 1994, pp. 22-26 [17] E. Kindler: SIMULA and Super-Object-Oriented Programming. From Object-Orientation to Formal Methods [Lecture Notes in Computer Science, Vol. 2635], Springer, Berlin – Heidelberg – New York, 2004, pp 165-182 [18] J. C. Strauss et al., The SCi Continuous System Simulation Language, Simulation, Vol. 9, No. 6, 1967, pp. 291-303 [19] J. Weinberger, Extremization of Vector Criteria of Simulation Models by Means of Quasiparallel Handling, Computers and Artificial Intelligence, Vol. 6, No. 1, 1987, pp. 71-78 [20] J. Weinberger, Evolutional Approach to Extremization of Vector Criteria of Simulation Models, Acta Universitatis Carolinae Medica, Vol. 34, No. 3/4, 1988, pp. 249-258 [21] O.-J. Dahl, Discrete Event Simulation Languages, Norsk Regnesentralen, Oslo, 1966. Reprinted in [22] [22] Genuys, F. (editor), Programming Languages, Academic Press, London – New York, 1968. [23] E. Kindler, I. Krivy and A. Tanguy, Reflective Simulation of Logistic and Production Systems, International Workshop on Harbour, Maritime and Multimodal Logistics Modelling & Simulation HMS, Modelling & Applied Simulation MAS 2002, Liophant Simulation Club, Genoa, 2002, pp. 97-102 [24] P. Bluemel and E. Kindler, Simulation of Antagonist Mutually Simulating Systems. Simulation und Animation '97, Society for Computer Simulation International, Erlangen, Ghent, Budapest, San Diego 1997, pp. 56-65
work according to the future states; the future states will be determined by using simulation performed on C [48]. JAVA was also taken into account but – apart from its poor tools for OOP and from its lack of security – it appeared very troublesome for defining efficient system of scheduling statements. Nowadays, SIMULA is an excellent tool, existing as free software for PC under Windows and – not free – for work stations. The official standard of this language (originally [10], nowadays [11]) offered a standard main class SIMULATION for scheduling; this class demanded certain its users to respect certain general restrictions the reason of that was security against transplantation (see 2.2) but recently a new main class for the same purpose was derived and implemented [49], which is as secure as SIMULATION but does not demand the restrictions.
Acknowledgements: This work has been supported by the Grant Agency of Czech Republic, grant reference no. 201/060612, name “Computer Simulation of Anticipatory Systems”.
References: [1] O.-J. Dahl, and K. Nygaard, Class and Subclass Declarations, Simulation Programming Languages, Proceedings of IFIP Working Conference on Simulation Programming Languages, Oslo 1967, North Holland, Amsterdam 1968, pp. 158-174 [2] D. C. R. Hill, Object-oriented Analysis and Simulation. Addison-Wesley, Harlow – Reading – Menlo Park, 1996 [3] G. Gordon, A General Purpose Systems Simulation Program. Proc. 1961 EJCC, MacMillan, New York, 1961. [4] T. J. Schriber, An Introduction to Simulation Using GPSS/HTM, Wiley, New York – Chichester – Brisbane – Toronto – Singapore, 1990 [5] Verfahrenorientiertes Programmiersystem fuer diskrete Simulation VOPS SIMDIS. Robotron, Dresden, 1974 [6] A. Schoene, Simulation technischer Systeme, Vol. 3, Hanser, Munich, 1976 [7] D. E. Knuth and J. L. McNealey, SOL – a Symbolic Language for General Purpose Systems Simulation. IEEE Transactions of Electronic Computing, Vol. 13, 1964, pp. 401-408 [8] L. A. Kalinichenko, SLANG – Computer Description and Simulation-Oriented Experimental Programming Language, Simulation Programming Languages, North-Holland, Amsterdam, 1968, pp. 101-115 [9] O.-J. Dahl and K. Nygaard: SIMULA, a Language for Programming and Description of Discrete Event
ISSN: 1790-5109
1058
ISBN: 978-960-6766-85-5
12th WSEAS International Conference on COMPUTERS, Heraklion, Greece, July 23-25, 2008
[25] E. Kindler, I. Krivy and A. Tanguy, Systematics of Nested Simulation, International Workshop on Harbour, Maritime and Multimodal Logistics Modelling & Simulation HMS 2003, Riga Technical University, Riga, 2003, pp. 191-195 [26] E. Kindler, I. Krivy and A. Tanguy, Object-Oriented System Analysis of Anticipatory Systems in Week Sense, International Journal of Computing Anticipatory Systems, Vol. 14, 2004, pp. 271-285. [27] J. Weinberger and A. Mojka, Optimization of an Industrial Simulation Model by Means of QuasiParallel Handling, Ekonomicko-matematický obzor (Economical and Mathematical Review), Vol. 19, No. 2, 1983, pp. 179-185 [28] J. Weinberger and M. Vydra, Heuristic Multicriterial Optimisation of Large Simulation Models, Proceedings of the Seventeenth Simula Users‘ Conference, University of Newcastle, Newcastle upon Tyne, 1990, pp. 71-82 [29] J. Faber and J. Weinberger, Thalamocortical Reverberation Circuit Simulation Using the Simula Language, Acta Universitatis Carolinae Medica, Vol. 34, No. 3/4, 1988, pp. 149-248 [30] E. Kindler and M. Brejcha, An Application of Main Class Nesting – Lee's Algorithm, SIMULA Newsletter, Vol. 13, No.3, 1990, pp. 24-26 [31] P. Bulava, Nested Simulation of Demografical Processes [PhD. Thesis in Czech], University of Ostrava, Ostrava, 2007 [32] P. Berruet, T. Coudert and E. Kindler: Conveyors With Rollers as Anticipatory Systems: Their Simulation Models, Computing Anticipatory Systems CASYS 2003, American Institute of Physics, Melville, New York, 2004 [AIP Conference Proceedings Volume 718], pp. 582-592 [33] E. Kindler, T. Coudert and P. Berruet: ComponentBased Simulation for a Reconfiguration Study of Transitic Systems, SIMULATION, Vol. 80, No. 3, 2004, pp.153-163 [34] E. Kindler, P. Berruet and T. Coudert, Conveyors with Rollers and Their Reflective Simulation, International Workshop of Modelling & Applied Simulation MAS 2003 [October 2-4, Bergeggi, Italy], DIP – Genoa University, Liophant Simulation Club, McLeod Institute of Simulation Science – Genoa Center, Genoa, 2003, pp. 147-152 [35] E. Kindler, I. Krivy, P. Lacomme and A. Tanguy, Simulation of FSM Including Automated Guided Vehicle, Proceedings of the 2003 European Simulation and Modelling Conference, Naples, 2003, EUROSIS-ETI, Ghent, 2003, pp 122-126 [36] E. Kindler, I. Krivy, P. Lacomme and A. Tanguy, Reflective Simulation Models for Optimization of FMS, European Simulation Multiconference ESM
ISSN: 1790-5109
’2004 [Paris, October 25-27, 2004], EUROSIS, Ghent, 2004, pp. 94-98 [37] E. Kindler, SIMULA and Concurrent Engineering, ASU Newsletter, Vol. 21, No 3, 1993, pp. 1-16 [38] M. Das: Oral Communication to the Author, West Virginia University, Morgantown, 1993 [39] E. Kindler, Simulation of Systems Containing Simulating Objects, Simulation und Integration'94 [ASIM Mitteilungen, Heft Nr. 42], ASIM, Magdeburg – Dortmund, 1994, pp. 65-76 [40] E. Kindler, When Everybody Anticipates in a Different Way ..., Computing Anticipatory Systems CASYS 2001, American Institute of Physics, Melville, New York, 2002 [AIP Conference Proceedings Volume 627], pp. 119-127 [41] E. Kindler, D. Patrone and D. Unali, A Contribution to Reflective Simulation of Queuing Management, Proceedings of the 35th Spring International Conference MOSIS,01 Modelling and Simulation of Systems, MARQ, Ostrava, 2001, Vol. 1, pp. 41-45 [42] P. Bulava, Transport System in Havirov. Proceedings of 28th ASU Conference, [Brno, September 26 – October 1, 2002]. FIT, VUT University of Technology, Brno, 2002, pp. 57-62 [43] E. Kindler, Classes for Object-Oriented Simulation of Container Terminals, Managing and Controlling Growing Harbour Terminals, The Society for Computer Simulation International, San Diego, Erlangen – Ghent – Budapest, 1997, pp. 175-278 [44] E. Kindler, Simulation Model of a Container Yard Containing a Simulating Computer, Harbour, Maritime & Industrial Logistics Modelling and Simulation HMS, The Society for Computer Simulation International, San Diego, 1999, pp. 3-8 [45] E. Kindler, Nesting Simulation of a Container Terminal Operating With its own Simulation Model, JORBEL (Belgian Journal of Operations Research, Statistics and Computer Sciences), Vol. 40, No. 3-4, 2002, pp. 169-181 [46] I. Krivy and E. Kindler, Synthesis of two Anticipatory Modes in Design and Life-Cycle of Hospitals, International Journal of Computing Anticipatory Systems, Vol. 18, 2006, pp. 75-85 [47] J. Gargulak, Reflective Simulation of Patients-inBed Movement [Master Thesis in Czech], Charles University, Prague, 2007 [48] E. Kindler, C. Klimes and I. Krivy, Simulation Study with Deep Block Structuring, Modelling and Simulation of Systems MOSIS 07, MARQ, Ostrava, 2007, pp. 26-33 [49] I. Krivy, E. Kindler: New Flexible Simulation Tool in SIMULA, The 2007 European Simulation and Modelling Conference Modelling and Simulation ’2007, EUROSIS-ETI, Ghent, 2007, pp. 124-128
1059
ISBN: 978-960-6766-85-5
