- Email: [email protected]
Building a Simulation Model for Real Time Systems
BUILDING A SIMULATION MODEL FOR REAL TIME SYSTEMS Chr. David, F. Madaule and H. G. Mendelbaum Universite Paris 6, 4
plo Jussieu, 75230 Paris, Cedex 05; Universite Paris 5, JUT, 143, Av. Versailles, 75016 Paris, France time (in the sequencing table), .to collect the measures in the statistical table.
INTRODUCTION The aim of this work is to study the design of Real Time systems oriented towards specific needs. A system is considered as a whole, made of the computer and its operating system. In this study, we build a tool which is a general simulation model for the description of evolutive systems in which some basic elements may be modified (such as the scheduling algorithms). With this tool, measures can be made on the various possibilities of one system in order to compare them.
b) The sequencing table is made of an an array with "preceding modules" as entries. One column indicates the status in which the call has been made. The second column gives the "following modules" to activate. The third column points out the data to transfer." The last columns record the names of the measure and evaluation routines to execute dur ing the transfer of control. (F i g. 3). In this evolutive simulator, a new system can be developped by implementing a new sequencing table, with the necessary modules.
Using this model, the design methodology of a system is to split it into independent modules and links.
c) measurements Measures are generally made at each transfer of control (links). But if necessary in some cases, the designer may do some performance evaluations inside some given modules. The last columns of the sequencing table may be filled in with appropriate measure and evaluation routines chosen by the designer and depending on the comparisons or evaluations he thinks necessary. Measure routines are often executed at each link, they generally record dates, count objects etc ..• Evaluation routines are generally executed at some specific links, they can make some computations on the measures (statistics, performance comparisons etc ••. )
The animation of this description enables the simulator to make specific measures on the work of the modules and on their linkages. This kind of problem have been studied by some authors (see bibliography 1 to 2 and 10 to 15). Our aim is different, we want to simulate the whole operation of a system to make easier the design.
A) SYSTEM DESIGN METHODOLOGY In order to design systems, we propose a tool which is a simulation model.
d) the statistical table The measures record may vary from one simulation to an other, the designer may define for each one a 2 dimensional array according to the measures and evaluations he has to do. Each line represents an object to be watched (memory Zone, interrupt signal, queue etc .•. ). Each column represents the type of measure (or statistic) to be made one these objects (occurence number, request dates, response times etc .•• ) (see fig. 4). Therefore, the parameters of the measure and evaluation routines are indexes in this statistical table.
This general model is made of a) a kernel which contains a sequencing table describing the links between the modules and a statistical table enabling to collect data for performance evaluations. d) modules which simulate how the operating system elements are working. The modules have no direct transfers between them. At the end of a module the control is always given to the kernel, which gives back the control and the nec~5sary informations to other modules according to its sequencing table.
1) SIMULATION MODEL :
* *
*
e) Modules are programs which simulate the work of the elements of the studied system (program, interrupt, peripheral devices etc ..• ).
a) the kernel's work is: to receive notifications from the modules, to find in the sequencing table the following modules to activate (with their data) according to the preceding modules and the status in which the call has been made, to find the measures to do at the transfer
According to the type of simulation needed, the modules will be written by the designer with more of less details. The work of each module is to give the time of execution of 173
174
Chr. David, F. Madaule and H. G. Mendelbaum
the simulated element and the modifications to do on the data to transfer.
~F~ig~u~r~e~~2
T1600-ABOS control links (RU scheduling algorithm) (6-7)
2) CONSTRUCTION OF A SIMULATION a) description of a system: The system that the designer wants to study has to be analyzed, first. For this analysis we choose to decompose systems in levels and sublevels in order to build an arborescence whose leaves represent the basic elements of the system. (see figure 1 for the ABOS system made on a Telemecanique T 1600 computer and Appendi s) Therefore we describe links between those elements. We define them as control links, they enable for instance activation of module A on request of module B with data transfer (example in figures 1 and 2). These links may me modified from one simulation to another depending on the choices made for the design of the operating systems (for instance scheduling algorithms).
interrupts i/O periph __ ~:_E~~~E~_________ _
RINT
IOCS----------------------------
I/O periph user program
CHP~GE--------------------------
IOCS
user I/O description program----- table ---------------
IOCS
IT timer-------~~~------------
INHOR
INHOR------~:-E!~2~------------ AUTOM------~:-2~~~-------------
CHANGE CHANGE
user 0 program----~--2~~~~-------------
AUTOM
RINT---~:-E!~2~-~~~~~-----------
AUTOM
b) Construction of the simulation for this example: The entries and columns of the sequencing table (cF fig. 3) are deduced from the links defined in the system analysis (control links, accesslinks etc ••• ). The various status of a same entry (i.e of a same preoeding module) depend on the condition in which the module is calling. In each case these following modules and their data must be written in the array. SYSTEM
- NON CRITICAL
Figure
arborescence for ABOS-T1600 system with RU scheduling algorithm (6-7)
PHASE
Building a simulation model
3) BUILDING NEW SIMULATIONS Figure 3 shows how the sequencing table is built for ABOS. For instance, the entries
of the table are made of the names of the elements defined in the analysis of the system (figures 1 and 2) : interrupts (IT), I/O peripheral devices programs etc ... Some modules can call the kernel in various status, for instance a user program may notify an I/O request or the termination of its execution. For each case, the third and fourth columns give the name of the module to which the control will be given and the data to transfer, for instance, the scheduling algorithm CHANGE can give the control to a user program (if the code is in core storage) or to the memory allocator ALOMEN with the nUmber of the program (if the code is on disk). The columns 5 and 6 give the measure and evaluation routines to execute in each case: DATE, COUNT, MEAN etc •.• with parameters making reference to the statistical table (figure 4). Detailed construction of the simulator for the RU algorithm (6-7) a) the arborescence and the links have been described for this algorithm in the paragraph 2 of this paper. So, we take the results of the figures 1 and 2 to build the simulator b) simulated modules of the operating system Taking the extremities of the control links, we find 9 modules to simulate : - RINT which receives the interrupts and transforms them in events - INHOR which receives the interrupts of the timer and also transforms them in events. AUTOM which receives events and transforms them in modules to be executed. - IOCS which receives the interrupts of the I/O peripheral devices and the requests of user program. - ALOMEN which receives a program to swap in and gives response when the program is in memory. - we have a module which simulates the occurences of the interrupts and - an other to simulate the timer interrupts - CHANGE which simulates the work of RU algorithm and finally the user programs. c) Measures
* Description
of the measures and evaluation routines: For the measures we define two kinds of actions : to count, and to get the time. So we build two measure routines : -DATE which gets the time and, in terms of the transmitted parameters, stores the information in the dedicated entry of the statistical table.
I~
• COUNT which adds one to a specific counter which is an entry of the statistical table. The indexes of the entry are paramaters of the routine. For the evaluation we define two routines : _ MEAN which computes a mean time of execution, of wait, of occupation •.• Parameters which are transmitted represent indices in the statistical table, where are stored : - the dates of the beginning and the end of execution -or the dates of the beginning and the end of the occupation- etc ... • COMP which, for each user program, counts how many time critical dates are overlapped. Description of the statistical table: In the last paragraphs we have defined what objects have to be measured and what kind of measures have to be done. So now the statistical table may be built. For example in the figure 4 we can see that for each interrupts we have 3 measures : number of occurrences arrival date, handling date and two evaluations : handling time and waiting time. ~
Animation of the simulation Let us now animate the simulation and see what happens in the sequencing table (figure 3) when : - an interrupt arrives : IT transfers control to RIN~which transforms the number of IT into an event and gives control to AUTOM. AUTOM reads the automata t~ble and finds the module to be executed, transfers the control to CHANGE which activates the module. If we just take the number of the corresponding entries in the sequencing table, the way is : 2-11--10--15. - a module terminates its execution, the dedicated way is : 15 13--10-( 16--8--15 - a user makes an I/O request in non blocking mode, the way is : 12--7 and the user program goes on its execution.
CONCLUSION We have presented here a new conception of simulator for evolutive real time systems and shown on some various examples how versatile it is. It has been written with the SIMULA language (8) (9) whose structure is very well adaptated to this kind of programming. But it could be easily written in other languages. This simulator may be used for various kinds of utilization. For examples : - it may be an help for the construction and evaluation of new systems. - it can be used for the comparison of various systems. - or it may be used to improve an existing system.
176
Chr. David, F. Madaule and H. G. Hendelbaum Figure 3 : sequencing table for ABOS - T1600 system (3-5) with RU algorithm (6-7) 2
PRECEDING MODULES
2
3
periph call I/O blocking mode periph call /0 non blocking :node
6
12
rrO TRANSFER nO IT
I
6
EVALUATION MEASURES
ROUTINES
COUNT (nOit,1) DATE (nOit,2)
nO periph
MEAN(nOit~
7)
CHANGE
nO prog
prog
I/O periph prog
DATE (IOCS,2) COUNT (IOCS, 1) DATE (prog,5) DATE (CHANGE, 2) COUNT (CHANGE, 1 )
desc.I/O, nO prog
DATE (prog,4) DATE (CHANGE, 2) COUNT (CHANGE, 1)
desc. I/O
DATE (prog,2)
MEAN (ALOME.N, 6)
MEAN (INHOR,6)
CHANGE
nO prog
INHOR
CHANGE
nO prog
DATE ( INHOR J 3 ) DATE (CHANGE, 2) COUNT (CHANGE, 1 )
AUTOM
CHANGE
nO prog
DATE (AUTOM,3) DATE (CHANGE, 2) COUNT (CHANGE, 1 )
RINT
AUTOM
I/O request
IOCS
termination of exec
AUTOM
USER
TIMER
INHOR user code in central memory
15
MEAN (RINT,6)
nOprog, desc.I/O
DATE (prog, 3) DATE (IOCS, 2) COUNT (IOCS, 1)
MEAN (prog, 6)
nOprog,evt
DATE (prog,3) DATE (AUTOM,2) COUNT (AUTOM,1)
MEAN (prog, 6)
time
prog
ALOMEM
MEAN (AUTOM, 6)
DATE (RINT,::) DATE (AUTOM,2) COUNT (AUTOM,1 )
evt,nOprog
HANGE user code on secundary memory
MEAN (prog,7)
DATE (prog,2)
ALOMEN
PROGRAM
16
5
DATE (ALOMEN]3) DATE (CHANGE~2) COUNT (CHANGE, 1 )
13
14
DATA
IOCS
user call I/O periph I/O blocking mode CHANGE user call I/O non blocking mode
7
11
RINT
I/O PERIPH
IOCS
10
MODULES
4
E~~ !~HH'~l
5
9
FOLLOWING STATUS
IT
4
8
3
nO prog
DATE (INHOR,2) COUNT (INHOR,1) DATE (prog,2) DATE (CHANGE, 3)
MEAN (CHANG~ 6) COMP (prog, 7 ,8)
DATE (ALOMEN',2 ) DATE (CHANGE, 3) COUNT (ALOMEN, 1 )
MEAN
(CHANG~
6)
Building a simulation model Figure 4
statistical table for ABOS-T1600 with RU algorithm
1 Objects
Number
2
Date
! Date I; Date 3
file of waiting of events entries
file of modules in critical phase file of modules in non critical phase
177
4
of arrival
5
6
7
8
Date
Time
Time
Time
of exit
of ~andling
11
11
11
11
11
11
11
11
of pccurence:
11
IT 0
.
. 7 user prog 1
ot overlap of critical date
. n
ot begin. of exec.
ot eg~
exec.
of b 5'lin. ev~nt wal. lng
of handling
ready
11
of exec.
of eVEnt wal. l.ng
of
w~nlng
of INHOR
11
11
11
exec.
CHANGE
11
11
11
11
AUTOM
11
11
11
11
RINT
11
11
11
11
ALOMEN
11
11
11
11
resource 1
. . n
of
of
request
request
of gt€J;iu l.on
of
of
of
release
waiting
occupat:Dr
Chr . David, F . Madaule and H. G. Mendelbaum
178
(conclusion following) - it may also be used by users of systems to study the real time execution of their applications. APPENDIX ABOS ON T1600 IT
OPERATING SYSTEM ' S DIAGRAM
IT
with RU algorith (3-5)
'0--------_
•
-~~0 '"
Qmodules ----. user request --+ transfer of control
I
I
e
CHARECTERISTICS OF THE COMPUTER T1600 has a micro-programmed scheduler dealing with softw3re tasks attached to 128 priority levels. Interrupts can be received on 8 priority levels, each one corresponding to a "hardware task". The timer is connected to the second level. This computer enables to execute a program anywhere in the core storage and to save the registers according to the policies of the memory allocator and the scheduler.
Each proposition means : when event e , arrives in state j with conditions c '1. k the new state of the automata is Cf ' new conditions c have to be set and mo~ule m 1 has to be ex~cuted with paramaters P1,P2 .••
er
BIBLIOGRAPHY
CHARACTERISTICS OF THE OPERATING SYSTEM ABOS can be split into 6 functional modules : - INHOR takes care of the timer interrupts. - RINT is a module which handles the interrupts. - AUTOM is the nucleus of the automata and so realises the links between the independant modules . - CHANGE allocates the central processor and determines which program runs and for how long. - ALOMEN allocates the central and secondary memories. - loeS is an interface between the users' programs and the I/O devices For an application with this system, a user must describe separatly the actions of the process control (in form of independant modules), and the linkings between them which appear in the central automata as a set of the form :
1 - Definition of construction of Realtime operating systems by basic functions. Purdue Europe, SCHROTT, Zurich, 1976. 2 - Operating system modules for process control application,SCHROTT, RUB, IFAC/ IFIP Symposium on software for computer control, socoeo, 1976, USSR. 3 - Automata as structured tools for realtime programming,H.G . MENDELBAUM, F. MADAULE, IFAC/IFIP workshop on real tim~ Boston, 1975. 4 - A class of structured real time systems centered on a descriptive nucleus, H.G MENDELBAUM, F. MADAULE, IFAC/IFIP symposium on software for computer control, soeoeo, USSR, 1976. 5 - On hardware/software distribution of real time systems, R. SAMUEL, H.G. MENDELBAUM, F. MADAULE, IFAC/IFIP International workshop on real time programming, IRIA, FRANCE 1976.
Building a simulation model
179
6 - Scheduling of time critical processe~ o. SERLIN Proceedings of AFIPS, SJCC 1972.
12 - Proc. 1st. IEEE International Conference on Software Engineering, San Francisco 1976.
7 - Ordonnancement des processus temps reel sur une ressource preemptive~ J. LABETOULLE, IRIA, Rapport de recherche, ma~ 1974.
13 - Wirth N. , MODULA, a language for modular multiprogramming, Software Practice and Experience, vol. 1, 1977.
8 - SIMULA 67 Common base Language. Norvegian Computing Center O.J. DAHL, B. MYRHAUG, K. NYGAARD, 1970. 9 - La programmation avec SIMULA 67. Librairie de l'Universite de Montreal, 1976. 10 - FALLA M.E, The GAMMA design and programming system, IFIP WG 2-3, meeting, dec. 1976. 11 - SEEGMULLER G, A survey of the language system ASTRA, a tool with aids in designing and controlling system software. Proc. Int. Summer School on language hierarchies and interface, Marktoberdorf, 1975.
14 - CHEVAL J. L., CHRI STIAN F., KRAKOWIAK S. LUCAS Ma. , MONTUELLE J. , MOSSIERES J. "Un systeme d'aide a l'ecriture des systemes d'exploitation" Congres AFCET, Paris, 1976. 15 - LUCAS Ma., "Conception modulaire des systemes d'exploitation. Methodes et exemple d'application" These Docteur Ingenieur, Grenoble, 1977.
plo Jussieu, 75230 Paris, Cedex 05; Universite Paris 5, JUT, 143, Av. Versailles, 75016 Paris, France time (in the sequencing table), .to collect the measures in the statistical table.
INTRODUCTION The aim of this work is to study the design of Real Time systems oriented towards specific needs. A system is considered as a whole, made of the computer and its operating system. In this study, we build a tool which is a general simulation model for the description of evolutive systems in which some basic elements may be modified (such as the scheduling algorithms). With this tool, measures can be made on the various possibilities of one system in order to compare them.
b) The sequencing table is made of an an array with "preceding modules" as entries. One column indicates the status in which the call has been made. The second column gives the "following modules" to activate. The third column points out the data to transfer." The last columns record the names of the measure and evaluation routines to execute dur ing the transfer of control. (F i g. 3). In this evolutive simulator, a new system can be developped by implementing a new sequencing table, with the necessary modules.
Using this model, the design methodology of a system is to split it into independent modules and links.
c) measurements Measures are generally made at each transfer of control (links). But if necessary in some cases, the designer may do some performance evaluations inside some given modules. The last columns of the sequencing table may be filled in with appropriate measure and evaluation routines chosen by the designer and depending on the comparisons or evaluations he thinks necessary. Measure routines are often executed at each link, they generally record dates, count objects etc ..• Evaluation routines are generally executed at some specific links, they can make some computations on the measures (statistics, performance comparisons etc ••. )
The animation of this description enables the simulator to make specific measures on the work of the modules and on their linkages. This kind of problem have been studied by some authors (see bibliography 1 to 2 and 10 to 15). Our aim is different, we want to simulate the whole operation of a system to make easier the design.
A) SYSTEM DESIGN METHODOLOGY In order to design systems, we propose a tool which is a simulation model.
d) the statistical table The measures record may vary from one simulation to an other, the designer may define for each one a 2 dimensional array according to the measures and evaluations he has to do. Each line represents an object to be watched (memory Zone, interrupt signal, queue etc .•. ). Each column represents the type of measure (or statistic) to be made one these objects (occurence number, request dates, response times etc .•• ) (see fig. 4). Therefore, the parameters of the measure and evaluation routines are indexes in this statistical table.
This general model is made of a) a kernel which contains a sequencing table describing the links between the modules and a statistical table enabling to collect data for performance evaluations. d) modules which simulate how the operating system elements are working. The modules have no direct transfers between them. At the end of a module the control is always given to the kernel, which gives back the control and the nec~5sary informations to other modules according to its sequencing table.
1) SIMULATION MODEL :
* *
*
e) Modules are programs which simulate the work of the elements of the studied system (program, interrupt, peripheral devices etc ..• ).
a) the kernel's work is: to receive notifications from the modules, to find in the sequencing table the following modules to activate (with their data) according to the preceding modules and the status in which the call has been made, to find the measures to do at the transfer
According to the type of simulation needed, the modules will be written by the designer with more of less details. The work of each module is to give the time of execution of 173
174
Chr. David, F. Madaule and H. G. Mendelbaum
the simulated element and the modifications to do on the data to transfer.
~F~ig~u~r~e~~2
T1600-ABOS control links (RU scheduling algorithm) (6-7)
2) CONSTRUCTION OF A SIMULATION a) description of a system: The system that the designer wants to study has to be analyzed, first. For this analysis we choose to decompose systems in levels and sublevels in order to build an arborescence whose leaves represent the basic elements of the system. (see figure 1 for the ABOS system made on a Telemecanique T 1600 computer and Appendi s) Therefore we describe links between those elements. We define them as control links, they enable for instance activation of module A on request of module B with data transfer (example in figures 1 and 2). These links may me modified from one simulation to another depending on the choices made for the design of the operating systems (for instance scheduling algorithms).
interrupts i/O periph __ ~:_E~~~E~_________ _
RINT
IOCS----------------------------
I/O periph user program
CHP~GE--------------------------
IOCS
user I/O description program----- table ---------------
IOCS
IT timer-------~~~------------
INHOR
INHOR------~:-E!~2~------------ AUTOM------~:-2~~~-------------
CHANGE CHANGE
user 0 program----~--2~~~~-------------
AUTOM
RINT---~:-E!~2~-~~~~~-----------
AUTOM
b) Construction of the simulation for this example: The entries and columns of the sequencing table (cF fig. 3) are deduced from the links defined in the system analysis (control links, accesslinks etc ••• ). The various status of a same entry (i.e of a same preoeding module) depend on the condition in which the module is calling. In each case these following modules and their data must be written in the array. SYSTEM
- NON CRITICAL
Figure
arborescence for ABOS-T1600 system with RU scheduling algorithm (6-7)
PHASE
Building a simulation model
3) BUILDING NEW SIMULATIONS Figure 3 shows how the sequencing table is built for ABOS. For instance, the entries
of the table are made of the names of the elements defined in the analysis of the system (figures 1 and 2) : interrupts (IT), I/O peripheral devices programs etc ... Some modules can call the kernel in various status, for instance a user program may notify an I/O request or the termination of its execution. For each case, the third and fourth columns give the name of the module to which the control will be given and the data to transfer, for instance, the scheduling algorithm CHANGE can give the control to a user program (if the code is in core storage) or to the memory allocator ALOMEN with the nUmber of the program (if the code is on disk). The columns 5 and 6 give the measure and evaluation routines to execute in each case: DATE, COUNT, MEAN etc •.• with parameters making reference to the statistical table (figure 4). Detailed construction of the simulator for the RU algorithm (6-7) a) the arborescence and the links have been described for this algorithm in the paragraph 2 of this paper. So, we take the results of the figures 1 and 2 to build the simulator b) simulated modules of the operating system Taking the extremities of the control links, we find 9 modules to simulate : - RINT which receives the interrupts and transforms them in events - INHOR which receives the interrupts of the timer and also transforms them in events. AUTOM which receives events and transforms them in modules to be executed. - IOCS which receives the interrupts of the I/O peripheral devices and the requests of user program. - ALOMEN which receives a program to swap in and gives response when the program is in memory. - we have a module which simulates the occurences of the interrupts and - an other to simulate the timer interrupts - CHANGE which simulates the work of RU algorithm and finally the user programs. c) Measures
* Description
of the measures and evaluation routines: For the measures we define two kinds of actions : to count, and to get the time. So we build two measure routines : -DATE which gets the time and, in terms of the transmitted parameters, stores the information in the dedicated entry of the statistical table.
I~
• COUNT which adds one to a specific counter which is an entry of the statistical table. The indexes of the entry are paramaters of the routine. For the evaluation we define two routines : _ MEAN which computes a mean time of execution, of wait, of occupation •.• Parameters which are transmitted represent indices in the statistical table, where are stored : - the dates of the beginning and the end of execution -or the dates of the beginning and the end of the occupation- etc ... • COMP which, for each user program, counts how many time critical dates are overlapped. Description of the statistical table: In the last paragraphs we have defined what objects have to be measured and what kind of measures have to be done. So now the statistical table may be built. For example in the figure 4 we can see that for each interrupts we have 3 measures : number of occurrences arrival date, handling date and two evaluations : handling time and waiting time. ~
Animation of the simulation Let us now animate the simulation and see what happens in the sequencing table (figure 3) when : - an interrupt arrives : IT transfers control to RIN~which transforms the number of IT into an event and gives control to AUTOM. AUTOM reads the automata t~ble and finds the module to be executed, transfers the control to CHANGE which activates the module. If we just take the number of the corresponding entries in the sequencing table, the way is : 2-11--10--15. - a module terminates its execution, the dedicated way is : 15 13--10-( 16--8--15 - a user makes an I/O request in non blocking mode, the way is : 12--7 and the user program goes on its execution.
CONCLUSION We have presented here a new conception of simulator for evolutive real time systems and shown on some various examples how versatile it is. It has been written with the SIMULA language (8) (9) whose structure is very well adaptated to this kind of programming. But it could be easily written in other languages. This simulator may be used for various kinds of utilization. For examples : - it may be an help for the construction and evaluation of new systems. - it can be used for the comparison of various systems. - or it may be used to improve an existing system.
176
Chr. David, F. Madaule and H. G. Hendelbaum Figure 3 : sequencing table for ABOS - T1600 system (3-5) with RU algorithm (6-7) 2
PRECEDING MODULES
2
3
periph call I/O blocking mode periph call /0 non blocking :node
6
12
rrO TRANSFER nO IT
I
6
EVALUATION MEASURES
ROUTINES
COUNT (nOit,1) DATE (nOit,2)
nO periph
MEAN(nOit~
7)
CHANGE
nO prog
prog
I/O periph prog
DATE (IOCS,2) COUNT (IOCS, 1) DATE (prog,5) DATE (CHANGE, 2) COUNT (CHANGE, 1 )
desc.I/O, nO prog
DATE (prog,4) DATE (CHANGE, 2) COUNT (CHANGE, 1)
desc. I/O
DATE (prog,2)
MEAN (ALOME.N, 6)
MEAN (INHOR,6)
CHANGE
nO prog
INHOR
CHANGE
nO prog
DATE ( INHOR J 3 ) DATE (CHANGE, 2) COUNT (CHANGE, 1 )
AUTOM
CHANGE
nO prog
DATE (AUTOM,3) DATE (CHANGE, 2) COUNT (CHANGE, 1 )
RINT
AUTOM
I/O request
IOCS
termination of exec
AUTOM
USER
TIMER
INHOR user code in central memory
15
MEAN (RINT,6)
nOprog, desc.I/O
DATE (prog, 3) DATE (IOCS, 2) COUNT (IOCS, 1)
MEAN (prog, 6)
nOprog,evt
DATE (prog,3) DATE (AUTOM,2) COUNT (AUTOM,1)
MEAN (prog, 6)
time
prog
ALOMEM
MEAN (AUTOM, 6)
DATE (RINT,::) DATE (AUTOM,2) COUNT (AUTOM,1 )
evt,nOprog
HANGE user code on secundary memory
MEAN (prog,7)
DATE (prog,2)
ALOMEN
PROGRAM
16
5
DATE (ALOMEN]3) DATE (CHANGE~2) COUNT (CHANGE, 1 )
13
14
DATA
IOCS
user call I/O periph I/O blocking mode CHANGE user call I/O non blocking mode
7
11
RINT
I/O PERIPH
IOCS
10
MODULES
4
E~~ !~HH'~l
5
9
FOLLOWING STATUS
IT
4
8
3
nO prog
DATE (INHOR,2) COUNT (INHOR,1) DATE (prog,2) DATE (CHANGE, 3)
MEAN (CHANG~ 6) COMP (prog, 7 ,8)
DATE (ALOMEN',2 ) DATE (CHANGE, 3) COUNT (ALOMEN, 1 )
MEAN
(CHANG~
6)
Building a simulation model Figure 4
statistical table for ABOS-T1600 with RU algorithm
1 Objects
Number
2
Date
! Date I; Date 3
file of waiting of events entries
file of modules in critical phase file of modules in non critical phase
177
4
of arrival
5
6
7
8
Date
Time
Time
Time
of exit
of ~andling
11
11
11
11
11
11
11
11
of pccurence:
11
IT 0
.
. 7 user prog 1
ot overlap of critical date
. n
ot begin. of exec.
ot eg~
exec.
of b 5'lin. ev~nt wal. lng
of handling
ready
11
of exec.
of eVEnt wal. l.ng
of
w~nlng
of INHOR
11
11
11
exec.
CHANGE
11
11
11
11
AUTOM
11
11
11
11
RINT
11
11
11
11
ALOMEN
11
11
11
11
resource 1
. . n
of
of
request
request
of gt€J;iu l.on
of
of
of
release
waiting
occupat:Dr
Chr . David, F . Madaule and H. G. Mendelbaum
178
(conclusion following) - it may also be used by users of systems to study the real time execution of their applications. APPENDIX ABOS ON T1600 IT
OPERATING SYSTEM ' S DIAGRAM
IT
with RU algorith (3-5)
'0--------_
•
-~~0 '"
Qmodules ----. user request --+ transfer of control
I
I
e
CHARECTERISTICS OF THE COMPUTER T1600 has a micro-programmed scheduler dealing with softw3re tasks attached to 128 priority levels. Interrupts can be received on 8 priority levels, each one corresponding to a "hardware task". The timer is connected to the second level. This computer enables to execute a program anywhere in the core storage and to save the registers according to the policies of the memory allocator and the scheduler.
Each proposition means : when event e , arrives in state j with conditions c '1. k the new state of the automata is Cf ' new conditions c have to be set and mo~ule m 1 has to be ex~cuted with paramaters P1,P2 .••
er
BIBLIOGRAPHY
CHARACTERISTICS OF THE OPERATING SYSTEM ABOS can be split into 6 functional modules : - INHOR takes care of the timer interrupts. - RINT is a module which handles the interrupts. - AUTOM is the nucleus of the automata and so realises the links between the independant modules . - CHANGE allocates the central processor and determines which program runs and for how long. - ALOMEN allocates the central and secondary memories. - loeS is an interface between the users' programs and the I/O devices For an application with this system, a user must describe separatly the actions of the process control (in form of independant modules), and the linkings between them which appear in the central automata as a set of the form :
1 - Definition of construction of Realtime operating systems by basic functions. Purdue Europe, SCHROTT, Zurich, 1976. 2 - Operating system modules for process control application,SCHROTT, RUB, IFAC/ IFIP Symposium on software for computer control, socoeo, 1976, USSR. 3 - Automata as structured tools for realtime programming,H.G . MENDELBAUM, F. MADAULE, IFAC/IFIP workshop on real tim~ Boston, 1975. 4 - A class of structured real time systems centered on a descriptive nucleus, H.G MENDELBAUM, F. MADAULE, IFAC/IFIP symposium on software for computer control, soeoeo, USSR, 1976. 5 - On hardware/software distribution of real time systems, R. SAMUEL, H.G. MENDELBAUM, F. MADAULE, IFAC/IFIP International workshop on real time programming, IRIA, FRANCE 1976.
Building a simulation model
179
6 - Scheduling of time critical processe~ o. SERLIN Proceedings of AFIPS, SJCC 1972.
12 - Proc. 1st. IEEE International Conference on Software Engineering, San Francisco 1976.
7 - Ordonnancement des processus temps reel sur une ressource preemptive~ J. LABETOULLE, IRIA, Rapport de recherche, ma~ 1974.
13 - Wirth N. , MODULA, a language for modular multiprogramming, Software Practice and Experience, vol. 1, 1977.
8 - SIMULA 67 Common base Language. Norvegian Computing Center O.J. DAHL, B. MYRHAUG, K. NYGAARD, 1970. 9 - La programmation avec SIMULA 67. Librairie de l'Universite de Montreal, 1976. 10 - FALLA M.E, The GAMMA design and programming system, IFIP WG 2-3, meeting, dec. 1976. 11 - SEEGMULLER G, A survey of the language system ASTRA, a tool with aids in designing and controlling system software. Proc. Int. Summer School on language hierarchies and interface, Marktoberdorf, 1975.
14 - CHEVAL J. L., CHRI STIAN F., KRAKOWIAK S. LUCAS Ma. , MONTUELLE J. , MOSSIERES J. "Un systeme d'aide a l'ecriture des systemes d'exploitation" Congres AFCET, Paris, 1976. 15 - LUCAS Ma., "Conception modulaire des systemes d'exploitation. Methodes et exemple d'application" These Docteur Ingenieur, Grenoble, 1977.