dennis@cod.UUCP (Dennis Cottel) (01/23/87)
We are considering using Ada to write a non-real-time simulation of
combat engagements. It would seem a perfect application of
object-oriented design to use Ada tasks to model the independently
operating combatants, and in fact, to use tasks to model independent
functions within the weapons and platforms.
The problem is to model the passing of real-world time while
maintaining the independence of the tasks. For instance, the combat
control logic may want to wait for either an enemy detection, or for
five minutes to pass before making a maneuver.
Ada provides a method for waiting for a period of real time to pass,
but this won't work for a simulation because modeled time may proceed
either faster or slower than real time. The obvious answer is to have
a 'clock' task(s) which accepts requests from other tasks to wait until
a given modeled time arrives, then releases the waiting tasks when
modeled time reaches that value. However, the clock can only advance
the modeled time to T1 when it knows that no other task is going to
make a request to be released at a time T2 < T1. This essentially
means that the clock process has to divine that all other tasks are
quiescent before advancing the modeled time. This is where I'm stuck.
It would presumably work to make the clock task a lower priority than
all other tasks, but priorities are not a part of the Ada definition.
All other solutions I can think of require kludgy calls throughout all
the tasks. This violates the original reason for taking a tasking
approach, namely, that the design of each independent object should not
need to know anything about timing in other objects, or the timing
implementation.
If there were a straightforward way to deal with this issue, the
resulting program should be quite clear and easy to understand.
However, the Ada books that I have seen don't deal with this particular
problem. Are there books or journals that do? Anyone have advice or
suggestions? How about actual experience writing code?
Dennis Cottel Naval Ocean Systems Center, San Diego, CA 92152
(619) 225-2406 dennis@NOSC.MIL sdcsvax!noscvax!dennisCONTR47@NOSC-TECR.ARPA.UUCP (01/23/87)
In the past I did extensive simulation of real-time computer systems using IBM's GPSS simulation system. It was necessary for me to know intimately the way that the GPSS kept track of simulated time. I believe that the problem is generic to simulation rather than being an Ada problem so I believe that the following is applicable. There was a master timekeeper which stepped the simulated time clock and looked around for things to do at each time step. The programmer (me) had to know the scan order in order to make sure that simulated events would take place in the same order as in the system being simulated. There was a command to force the timekeeper to scan if you needed it to at a certain place in the program. The timekeeper scan took a significant amount of cpu time and motivated even more intimate inquiry into its workings. GPSS moves transactions from operation block to operation block which might simulate the movement of ships in a harbor. When you program a delay block the system computes the delay time and posts the end of delay as an event on a future events chain. Thus the timekeeper doesn't have to scan that delay block at each time step. The programming challenge then is to write your program in such a way that every event can be pulled from the future events chain and no time stepping/scanning is necessary. Simulated time then proceeds steady-by-jerks from event to event. This minimizes cpu time. The GPSS advanced programming manual told you how to do this. My suggestion is that you get an "introduction to GPSS" manual if they are still around or the internal documentation on any such simulation system, then build it in Ada if you must. It will probably be cheaper to just buy a simulation system for your PC if thats enough compute power. Pritzker and Associates has a product line called SLAM in Fortran where you get the timekeeper source code. Your bookstore or library may have a SLAM textbook. It sounds like you are on the road toward an object-oriented simulation system which sounds very worthwhile to me. You can then add numerical integration of differential equations etc... regards, sam harbaugh ---------------------
sommar@enea.UUCP (Erland Sommarskog) (01/24/87)
In article <469@cod.UUCP> dennis@cod.UUCP (Dennis Cottel) writes: >We are considering using Ada to write a non-real-time simulation of >combat engagements. It would seem a perfect application of >object-oriented design to use Ada tasks to model the independently >operating combatants, and in fact, to use tasks to model independent >functions within the weapons and platforms. > > ... further description of problems with clock tasks > First of all: I don't know anything of these combats that you are simulating. Is there any difference in the sense of simulation compared with for instance a telephone exchange? As far as I can read from your article, there is not. This is what I am assuming in the following. I don't think that Ada tasks are good tools to model the combatants. Tasks are real-time processes, while those you have, are not. That doesn't mean that I think it is bad idea to use Ada and OOD to solve the problem. It is just the approach that is wrong. What you need is non-real-time processes with non-real-time delays. In fact you will probably need a whole support package/generic/whatever for discrete-time simulation. Ada does not have this, however there is one langauge that actually have this as a standard feature, and that is Simula. If you don't know of the standard class SIMSET, I think you shall take a look at it. Probably it is exactly what you need. The problem will then be to implement SIMSET in Ada. Your simulation will be quite solve then, AND you will have good package for the next time.
sdl@MITRE-BEDFORD.ARPA.UUCP (01/26/87)
> We are considering using Ada to write a non-real-time simulation of > combat engagements.... > > The problem is to model the passing of real-world time while > maintaining the independence of the tasks.... > > Ada provides a method for waiting for a period of real time to pass, > but this won't work for a simulation because modeled time may proceed > either faster or slower than real time. The obvious answer is to have > a 'clock' task(s) which accepts requests from other tasks to wait until > a given modeled time arrives, then releases the waiting tasks when > modeled time reaches that value. However, the clock can only advance > the modeled time to T1 when it knows that no other task is going to > make a request to be released at a time T2 < T1. This essentially > means that the clock process has to divine that all other tasks are > quiescent before advancing the modeled time. This is where I'm stuck. All true! A number of Ada hackers (myself included) have independently found a reasonable solution to this problem. Assume that simulation processes are implemented by Ada tasks. Simulated time is not allowed to "pass" until all of the processes have "reported in" that they have no more events to schedule (so they can all be suspended). The simulation executive task (in control of advancing simulated time) simply keeps a count of how many simulation process tasks have reported in; it suspends each in turn. Once all of them have been suspended, the executive can then advance time to the next event. Whichever process task is supposed to deal with that event is then "reawakened" by the simulation executive, and so on. Voila! This, of course, requires that the process tasks be reactivated in an order different from the order in which they were suspended. To do this, "agent" tasks (visible to and controllable by the simulation executive) are used as intermediaries. Cf: "Implications of the Ada Environment for Simulation Studies," P. Friel and S. Sheppard, Proceedings of the 1984 Winter Simulation Conference. The authors are from Texas A & M University Comp. Sci. department, which has done much fine research (& written many papers) on the subjects of simulation in Ada, distributed simulation, etc. BTW, Dr. S. Sheppard and Dr. K. Murray emailed me the Ada source code of their simulation system. It appears to work OK. I believe it would be a fine submittal to the Ada Repository. (Are you listening, by any chance?) Steven Litvintchouk MITRE Corporation Burlington Road Bedford, MA 01730 (617)271-7753 ARPA: sdl@mitre-bedford UUCP: ...{cbosgd,decvax,genrad,ll-xn,philabs,security,utzoo}!linus!sdl
BBardin@ADA20.ISI.EDU.UUCP (01/26/87)
In response to your question regarding the use of Ada to write non-real-time simulations of combat engagements, I believe that we can help. We have recently developed an Ada package called Ada_Sim that supports discrete event simulation modeling directly in Ada. Ada tasks are used in the model to represent software tasks in a multi-tasking or distributed environment, hardware activity, and the external scenario. The Ada_Sim package is actually a collection of packages that provide future event chain and simulation clock management as well as functions that support the definition, use and statistic gathering on simulation entities such as resources, actions, queues, semaphores, and tasks. An application model is then constructed from Ada logic that uses these procedures to simulate the contention for resources, the passage of time, queuing of data, and the synchronization of tasks. Ada_Sim was successfully used to develop a model of an EW system in support of software design issues. The model consisted of 35 system tasks and 5 external load tasks. Statistics during model executions were gathered on: processor utilization, operating system utilization, application task utilization, queue sizes and delays, and the impact of different application priority schema. Any comments or questions are welcome, you can contact me on the net via BBardin at Ada20.ISI.EDU or by telephone. Barry McArdle Hughes Aircraft Co., Ground Systems Group, POB 3310, MS618/P215, Fullerton, Ca 92634. (714) 732-3762 -------
Mats_Ohlin_FOA2@QZCOM.MAILNET.UUCP (03/04/87)
My impression (shared with many other people having knowledge of both SIMULA and Ada) is that Ada will NOT be a good simulation language in its current form. It will gives simulation capabilities similar to those that may be built in say Pascal. The two main things Ada lacks for general purpose simulation are: 1. Lack of a simple and fast co-routine mechanism. 2. Lack of a general task type (which is needed for efficient and general handling of event lists /built, of course, as priority trees/). A subclass mechanism (what Intel calls "extended objects") would facilitate the transgression from SIMULA experience and modelling techniques, but goes contrary to the path Ada has selected for this problem, i.e. generics. According to an object-oriented approach to modelling, I cannot help thinking that the subclass concept in many cases is superior. Experience from the use of SIMULA clearly indicates that qualification checks in many cases can be done during compilation time, those few that are checked during execution gives a very small overhead (contrary to the belief of many otherwise well-informed specialists, especially in the US I have to say). -- Mats Ohlin, Swedish National Defense Research Institute Mats_Ohlin_FOA2%QZCOM@MULTICS.MIT.EDU