This system has been defined in USL; and automatically analyzed and
automatically generatated/resource allocated (RAT)ed to C code using the
001 Toolsuite.
TMAP
OPERATIONS
and STRUCTURES
1 simulator.
simulator processes a simulation database that is
loaded from a file named "./input.simdb.omap". The user then is free to
edit and store the simulation database before a run. The database queues
are examined to determine which events to process. This is repeated until
both queues are empty. When the simulation is complete, the results are
presented to the user running the simulation. And finally, the results
(which may have been edited by the user) are stored to disk in the file
named "./output.simdb.omap".
loadeditstoredisplay loads an object of type
TYPE using the path, omappath. Once loaded, the object is displayed using
the configuration in a display file:
displaypath/typename.omap
After the user has a chance to edit the OMap, it is stored to disk and the
result is returned as t.
is_finished checks if both the ready queue and the
events queue of the simulation database (SDB) are empty. If they are, then
finished will be "TRUE"; otherwise, it will be "FALSE".
process_queue processes the events queue of the
simulation database, simDB, resulting in S. An event is selected. If the
event is a job, then it is put onto the readyQ. If the event is a machine
event, then a machine resource is released for use by other jobs.
select_event removes an
event E from the events queue of the simulation database S0. The
simulation clock time of S0 is revised by adding the event time of E to
S0's clock time to get an updated S0 simulation clock time for S.
release_resource
returns the machine associated with event to the set of free machines after
it has finished processing. The jobProcess is evaluated to determine if
all of the jobOperations have been completed. If so, then the history is
updated; otherwise, the job with its next jobOperation is inserted into the
ready queue according to its original priority. This results in simDB
being updated to be S.
machine_state_update currently just returns machine to
the resource pool of simDB resulting in S. Further expansion of this FMap
could update the utilization time of the machine so that later analysis
could determine how often it was used.
priority_insert recursively goes through the ready jobs
of the readyQ of simDB in order to insert a new job, job, into the ready
queue. Each job has an priority number (represented as a Nat) indicating
its importance. Lower priority numbers are more important than higher
priority numbers. When a larger priority numbered job (i.e., a job of less
importance) is found, then the new job is inserted to the left, before,
the lower priority job in the ready job queue. This results in an updated
simulation database S.
update_history
logs the job completion time, endtime of job, by putting endtime into
times of the completed job, job. Then, the simulation database, simDB, is
updated by inserting the finished job into the history of simDB resulting
in S.
put_onto_readyq
updates the simulation database, simDB, readyQ with an_event, event,
job eventtype. First, the current simulation readytime is assigned to the
job. Then, a new readyQ priority is made by adding a "1" to the current,
old priority. This new priority is then assigned to the job. Finally, the
job that was removed from the event and now deemed to be a ready job is
inserted at the end of the jobs of the readyQ. The simulation database, S,
containing this updated reayQ is returned as output to Put_Onto_ReadyQ.
do_events processes the jobs
on the ready queue of the simulation database, simDB, resulting in S. If
the ready jobs to be processed is empty, simDB is returned as S with no
change. If there are more jobs that are ready than can be handled by the
set of available machines in the resource pool, those remaining jobs will
be processed in a successive interation of the simulation, once allocated
machines have been put back into the resource pool.
do_ready_job determines if there is a free machine in Ms0 to perform
the current job in the ready queue ReadyJobs. If the job can be done by a
machine, then the machine is removed from the resource pool; and, the ready
job is removed from the readyQ. The ready job is put in a Machine
EventType Event. This event is then scheduled based on its runtime and the
set of current events being worked on by other machines. On success, the
new states of the readyQ (RJs), the events queue (Es) and machine resource
pool (Ms) are returned. In the case when no machine in the resource pool
is able to do the ready job, no changes are made to ReadyJobs, Es0 and Ms0.
get_free_machine finds a machine from the machine resource pool,
machines. which can perform the current jobProcess jobOperation of job. M
will be the machine and Ms will be the resource pool with M removed. If
there is no machine available, then M will have a reject value. This
reject value can then be used by the calling FMap to determine if there was
a free machine.
will_machine_do_job examines the MachType of the
machine, mach, to make sure that it is appropriate for the current
jobProcess jobOperation of the job, job, to be performed. If it is, and
further validation shows that the machine has the capability to perform the
jobOperation, then willdo will be set to "TRUE"; otherwise it is set to
"FALSE".
does_op_match_capability examines capabilities for a capability with
the same name as OpName, the jobOperation name. If the capability exists,
then B will be "TRUE"; otherwise it will be "FALSE".
compute_run_time
computes the runtime a machine takes to perform a jobOperation of a
job, job. This is computed by finding the capability needed by the
machine, machine, to perform the job operation. Given the machine's
capabilty time and the number of units of work needed by the job operation,
the runtime = "thenumberofunits" times "thecapabilitytimeperunit". Note
that different machines having the same capability to process a job
operation may have a different time per unit of work. In the current
system this has not been considered; but the system could be revised to
take this into account. If this were to be done, one would want to revise
"Will_Machine_Do_Job" to select the machine with the capability that best
suites the chriteria needed by a particular job.
If the machine does not
have the expected capability, runtime is set to "0". Note, that this
should never happen, since the function, Will_Machine_Do_Job, has evaluated
the machine to see if it is the right machine type to do the job; and in
addition that it has the capability to perform the job operation.
findel_1 finds the first element of the set set, s,
that matches some criteria using the input, 1. Matching is done using MATCH
with the following interface: Boolean=Match?(element,1).
If a
element is found, then it is returned as e. If a element is not found, a
REJECT element is returned for e.
Interface: e:Any=findEL_1(s:Any)
()
1.4.1.3 compute_process_time.
compute_process_time
updates the amount of processtime that a job, job, has been in
processing using runtime. Each time a job operation is processed by a
machine, another increment of processing time is added to the processtime
of a job. When all of the job operations for a particular job have been
completed and the job is put into History, processtime will be the
cumulation of all of the runtimes on the machines that were needed to
process a job. Once the processtime of a job is updated here for this
particular runtime, it returned as J.
allocate_job allocates the next jobprocess of a job, job, to the
machine, mach. After going to the next job operation of the jobprocess
set, the currency is implicily set to this next job operation. This is
done using a "moveto:joboperation,jobprocess" ...
"upto:jobprocess,joboperation" sequence. The upto operator sets the
currency implicitly. This allocation results in a new machine event E to
be scheduled.
schedule_event looks at
each job in the events queue recursively summing the relative times of each
event. When this sum is greater than the input time, runtime, then event
is inserted into the queue. This results in an updated events queue, Es.
editdisplay displays an object t0 (of type TYPE for the
user to edit. Once editing is completed, the edited object t0 is returned
as t.
Interface: t:Any=EditDisplay(t0:Any)
()
1.6 storeomap.
storeomap puts the in memory object t0 into a file as
persistent disc storage. The file name is constructed by appending,
TYPE.omap, to prefix, the type of t0. t has the same value as t0. See
storeomap and it's related functions dstoreomap and destoryomap, all in the
a1 resuse library.