- Email: [email protected]
Simulative Analysis and Testing of Computer Control Systems
SIMULA TIVE ANALYSIS AND TESTING OF COMPUTER CONTROL SYSTEMS D. Rudolf Department of Technical and Biomedical Cybernetics, Institute of Technology Ilmenau, Ilmenau, G.D.R.
Abstract.The paper presents a method for analysing and testing computer control systems by simulation technique. The used models of computer software, hardware and the process controlled are described. The author discusses both experiences gathered from the implementation of a simulation program in assembly language on a control computer and results of its application. There were two computer control systems investigated: An hypothetic one to verify the correctness of the simulation program and to obtain some basic information about the behaviour of software systems and a computer control system implemented in practice to evaluate its hardware and software design. The author concludes the suitability of modelling and simUlation to analyse and test particularly the software project at early stages of computer control systems' development. To increase the adaptivility to concrete computer systems and user requirements of both models and simulation programs there is a nessecity to implement a simUlation language for structured and interactive processes in complex control systems. Keywords. Computer aided system design; computer evaluation; computer software testing; simUlation of computer control systems. INTRO])UCTION
system.
There are some techniques to evaluate the software and hardware structure of computer systems desi~ned to control a specific process (Yourdon, 1972) namely empirical formulas, mathematioal modelling, simulation and measuring techniques.
Simulation. Simulation allows compucontrol systems to be evaluated at early stages of design. The resemblance between the model used and the real system may be increased during the design process. Simulation can help to invent new and better approaches to a problem if the consequences of some changes are examined in the course of implementation. ~er
Empirical formulas. Empirical formulas have either been set up by system designers in watohing computer control systems in operation or are based an calculations from average activity rates and service times. They can be useful to clasify systems and answer this question: Can the system at all perform the tasks it is supposed to do?
Measuring techniques. They require interference into systems implemented in practice and may be used rather to analyse a system than to develope it. On the other hand the measured results are most trustworthy taking into account some measuring failures. According to the goal to develop a technique for analysis and test of oomputer oontrol systems at early stages of development the author chose simulation.
Mathematioal mOdellin~. Mathematical modelling mainly base on queuing theory can be used in oertain welldefined situations to made some useful oaloulations. The disadvantages are that mathematical models operate with most unknown activity rates, simple priority disCiplines, the independenoe of parallel processes and rarely inolude all resouroes of the
REQUIREMENTS The simulation program had been written in assembly language to be run on a oontrol oomputer with its limited 155
D. Rudolf
156
Simulative Analysis and Testing of Computer Control Systems memory capacity and meet both run time and limited memory requirements. Further on the simulation program is to be easy to handle, data are to be noted in a way familiar to the user and the results are supposed to give hints for improving the control system (hardware and software) structure. The possibility of tracing system activitie s i s required for testing purposes. MODEL The model developed is based on hardware and software structure of the ROBOTRON 4000 control computer system without external memory, particularlyon its supervisor ESKO 4000 (ESKO means Core Oriented Real Time Supervisor). The model mentioned is algorithmic and dynamic: All processes are described by algorithms and their realization times. The model includes control computer hardware, software and to some extent the process being controlled. The hardware components build up a resource network and the software component s a network of algorithms. Each resource can be characterized by a state model and its possible interstate changes. That also applies to programs bein ~ :ealizations of algorithms. A wal. b.ng room (queue) described by the priority rule and its structure is assigned to each resource. The simulation is event stream oriented and based on keeping track of the condition or state of hardware, software and process components.
rupts are disabled (supervisor state). Application programs are run in program state in which interrupt s are enabled. The state graph of application programs is shown in Fig . 3. The interstate changes mo s tly bear the supervisor call identifiers used in ROBOT.::l. ON 4 000 software. 1 he states are the follo wing: IDLE. There is no request for the program. PREVENTED. The program is prevented from running ; no request will be taken int o account. RUNNABLE. The program bit in the CPU queue is set; the pro gram ls ready to run. RUNNI NG. There is only one program running at a time. SUSPErmED . The program l s waiting for an event generated by another program. DELAYED . The program is waiting for a determined time. WAITING. The program waits for completing an input/output operation. 1
As programs are simulated on the level of decisions leading to interaction with other programs and the instructions between the s e decisions are replaced by their reali z ation time, there i s no simulation of process data and proce ss data processing. Thus the model of t he process controlled cannot consist in generating process data. But if it should be possible the process may be described by a process event table. Consequently the position of a revolving pointer determines the control flow in application programs. The events may be generated stochastically with a choosen distribution. SIMULATION PROGRAM The simulation program is written in overlay technique ( Risak, 1971) because of the limited core memory. Program root, subroutine library and two segment pages require 14 k words. It consists mainly of four subsystems.
Fig. 1. State graph of the CPU Figure 1 e.g. shows the state graph of the central processing unit (CPU), Fig. 2 the CPU queue structure of ES KO 4000. Each program can be activated once at a time (application programs eventually twice). Further requests are ignored. A mixed absolute/relative priority rule divides the queue in priority levels with absolute priority between and relative priority within them. During the execution of some programs inter-
L oadin~
system. Its tas k is to read the da a about structure and parameters of the computer control system and the process, convert them and arrange the data base for the other sub-
157
Computer control syst ems
D. Hudolf ~
' \11
-, \ 'i , ~
..
Program state (Application programs)
."
\
PL4
Supervisor state (Supervisor programs)
PoWQr supply interrupt
PL3
Error handling
Clock inteft upt Supervisory se rvices
Process interrupts _(!.!P~L=-0:=.L.._ _ _ _ _-'
PL 1 System interrupts (ch_~ne Is
L_________
-..J
I
I
Position of an interrupted application program of PL1
Fig. 2. CPU queue structure of ESKO 4 000 PL-Priority Level systems. It is also possible to get a - Statistics describing the time bedump of the data base at any time duhaviour of application programs ring simulation to continue or repeat such as minimum, maximum and mean simulation later. service time and program request losses. Simulating sysiem. This subsystem organizes the even oriented simulation Testing system. Testing systems for process, from which data are gathered the instruction by instruction test by a sampling routine. A data block of single programs are well-known. the length being 4 words consists the The testing system described here actual time, event number and event allows to test computer control syspecific information. These data are stems event by event, especially the buffered in a data buffer of 4 k words control flow through a system of inlength and then stored in a disk meteractiveapplication programs supermory. The simulator processes about visor call by supervisor call. This 300 events per second. will be useful for software system testing. The system designer can deAnalysing system. The analysing sy~ fine "test report points" (the system compUtes statistics of the following prints a report and continues simulatypes from the data gathered: tion), "test interrupt pointsll (the - Statistics that describe the utilisystem prints a report and stop simuzation of the system's resources, in lation) depending on varying conditions; particular CPU utilization (idle time, supervisor state time, program he can also influence the simulation flow by changing the data base. state time). S.F.C ('. -
f-'"
158
D. Rudolf
Simulation Analysis and Testing of Computer Control Systems
ficient is much stronger than the dependence on the kind of distribution. - The possibility to note more than one request at a time can also be of importance for the system behaviour. - Systems with high CPU utilization are better organized in a cyclic way than interrupt oriented.
variation coefficient." 1
Fig. 3. state graph of application programs RESULTS There were two computer control systems investigated: An hypothetic one to verify the correctness of the simUlation program and obtain some basic results concerning information about the behaviour of software systems and a computer control system implemented .in practice; the process controlled is a coal-bunker filling process. com uter control s stem. e app ca on so ware cons s s of twenty independent application programs of equal realization time. They are assigned to the four priority levels five programs on each level. All twenty programs are activated by the same interrupt with a stochasti~ interarrival time. It is easy to calculate the CPU idle time and general request losses as functions of the arrival rate supposing periodical activation. Figures 4, 5 and 6 show these theoretical results in comparison with simulation results using different distributions of interarrival time (Fig. 4), different :(larameters of the same distribution lFig. 5) and the possibility to consider one or two requests for each program at a time (Fig. 6). It can be ooncluded that - the influence of the variation co~
normal
50
11crit
Fig. 4. CPU idle time as function of interrupt rate for different distributions
normal distribution
50
variation coefficient
7tcrit
l\.
Fig. 5. CPU idle time as function of interrupt rate, different variation coefficients
Computer control systems
159
time percentage amounting to about 99 per cent. There is an essential dissemblance between CPU speed and memory utilization.
D. Rudolf
100 normal distribution variation coefficient El
1,0
ti = Number
of program pxecutrons Number of process events
number of poss',ble request notes 1
50
ProQram 4
t---------......:...~~!..!...!!L--
0,5 Program 2 Program '3 Program 1
ltcr',t
Fig. 6. CPU idle time as function of interrupt rate,one or two requests possible at a time Coal-bunker filling process. The application software consists mainly of five application programs controlling the process, which are closely interacting. The prooess can be described by a oyclic process event table with events occurring if the oontent of a bunker reaches a level of nearly 0, 50 or 100 per cent. Investigations were made to find out CPU idle time and program execution factors as functions of average prooess event (interrupt) rate. The results for periodic activation are i~ dicated in F~ 7 and 8. A program
100
200
Fig. 8. Program execution factors as function of interrupt rate CONCLUSIONS The suitability of modelling and simUlation of analyse and test computer control systems, particularly the software, at early stages of design can be concluded. The model presented is based on a specific control computer system. There is a nessecity to implement a simulation language for structured and interactive processes in complex control systems including mass storages and multiprocessing to increase the adaptivility of models and simulation programs to varying computer systems and user requirements. REFEREnCES
.... 98,S
......
........ . 1' ......
theoret,cal
..........
98+------r----~------+-~
100
200
300 71 [h -1]
Fig. 7. CPU idle time as function of interrupt rate system deadlock is the reason for the sudden increase of CPU idle time at a process event rate "A = 156 h- 1 • In this case two programs prevent themselves and others from execution and their program execution factors drop down to zero. The system can never perform its task. A rather surprising fact was the high CPU idle
Risak, V. (1971). Simulation von Digitalrechnern. Computer Monographien 6. Carl Hanser Verlag, MUnchen ROBOTRON 4000 (1973). Systemunterlagen-D okument at ion. VEB Robotron, Zentrum fUr Forschung und Technik, Dresden Rudolf, D. (1979). Simulative Analyse und Testung von ProzeDrechneranwendungssystemen. Arbeitsmaterial der Technischen Hochschule Ilmenau Yourdon, E. (1972). Design of On-line Computer Systems. Prentice Hall, Inc., Englewood Cliffs, New Jersey.
Abstract.The paper presents a method for analysing and testing computer control systems by simulation technique. The used models of computer software, hardware and the process controlled are described. The author discusses both experiences gathered from the implementation of a simulation program in assembly language on a control computer and results of its application. There were two computer control systems investigated: An hypothetic one to verify the correctness of the simulation program and to obtain some basic information about the behaviour of software systems and a computer control system implemented in practice to evaluate its hardware and software design. The author concludes the suitability of modelling and simUlation to analyse and test particularly the software project at early stages of computer control systems' development. To increase the adaptivility to concrete computer systems and user requirements of both models and simulation programs there is a nessecity to implement a simUlation language for structured and interactive processes in complex control systems. Keywords. Computer aided system design; computer evaluation; computer software testing; simUlation of computer control systems. INTRO])UCTION
system.
There are some techniques to evaluate the software and hardware structure of computer systems desi~ned to control a specific process (Yourdon, 1972) namely empirical formulas, mathematioal modelling, simulation and measuring techniques.
Simulation. Simulation allows compucontrol systems to be evaluated at early stages of design. The resemblance between the model used and the real system may be increased during the design process. Simulation can help to invent new and better approaches to a problem if the consequences of some changes are examined in the course of implementation. ~er
Empirical formulas. Empirical formulas have either been set up by system designers in watohing computer control systems in operation or are based an calculations from average activity rates and service times. They can be useful to clasify systems and answer this question: Can the system at all perform the tasks it is supposed to do?
Measuring techniques. They require interference into systems implemented in practice and may be used rather to analyse a system than to develope it. On the other hand the measured results are most trustworthy taking into account some measuring failures. According to the goal to develop a technique for analysis and test of oomputer oontrol systems at early stages of development the author chose simulation.
Mathematioal mOdellin~. Mathematical modelling mainly base on queuing theory can be used in oertain welldefined situations to made some useful oaloulations. The disadvantages are that mathematical models operate with most unknown activity rates, simple priority disCiplines, the independenoe of parallel processes and rarely inolude all resouroes of the
REQUIREMENTS The simulation program had been written in assembly language to be run on a oontrol oomputer with its limited 155
D. Rudolf
156
Simulative Analysis and Testing of Computer Control Systems memory capacity and meet both run time and limited memory requirements. Further on the simulation program is to be easy to handle, data are to be noted in a way familiar to the user and the results are supposed to give hints for improving the control system (hardware and software) structure. The possibility of tracing system activitie s i s required for testing purposes. MODEL The model developed is based on hardware and software structure of the ROBOTRON 4000 control computer system without external memory, particularlyon its supervisor ESKO 4000 (ESKO means Core Oriented Real Time Supervisor). The model mentioned is algorithmic and dynamic: All processes are described by algorithms and their realization times. The model includes control computer hardware, software and to some extent the process being controlled. The hardware components build up a resource network and the software component s a network of algorithms. Each resource can be characterized by a state model and its possible interstate changes. That also applies to programs bein ~ :ealizations of algorithms. A wal. b.ng room (queue) described by the priority rule and its structure is assigned to each resource. The simulation is event stream oriented and based on keeping track of the condition or state of hardware, software and process components.
rupts are disabled (supervisor state). Application programs are run in program state in which interrupt s are enabled. The state graph of application programs is shown in Fig . 3. The interstate changes mo s tly bear the supervisor call identifiers used in ROBOT.::l. ON 4 000 software. 1 he states are the follo wing: IDLE. There is no request for the program. PREVENTED. The program is prevented from running ; no request will be taken int o account. RUNNABLE. The program bit in the CPU queue is set; the pro gram ls ready to run. RUNNI NG. There is only one program running at a time. SUSPErmED . The program l s waiting for an event generated by another program. DELAYED . The program is waiting for a determined time. WAITING. The program waits for completing an input/output operation. 1
As programs are simulated on the level of decisions leading to interaction with other programs and the instructions between the s e decisions are replaced by their reali z ation time, there i s no simulation of process data and proce ss data processing. Thus the model of t he process controlled cannot consist in generating process data. But if it should be possible the process may be described by a process event table. Consequently the position of a revolving pointer determines the control flow in application programs. The events may be generated stochastically with a choosen distribution. SIMULATION PROGRAM The simulation program is written in overlay technique ( Risak, 1971) because of the limited core memory. Program root, subroutine library and two segment pages require 14 k words. It consists mainly of four subsystems.
Fig. 1. State graph of the CPU Figure 1 e.g. shows the state graph of the central processing unit (CPU), Fig. 2 the CPU queue structure of ES KO 4000. Each program can be activated once at a time (application programs eventually twice). Further requests are ignored. A mixed absolute/relative priority rule divides the queue in priority levels with absolute priority between and relative priority within them. During the execution of some programs inter-
L oadin~
system. Its tas k is to read the da a about structure and parameters of the computer control system and the process, convert them and arrange the data base for the other sub-
157
Computer control syst ems
D. Hudolf ~
' \11
-, \ 'i , ~
..
Program state (Application programs)
."
\
PL4
Supervisor state (Supervisor programs)
PoWQr supply interrupt
PL3
Error handling
Clock inteft upt Supervisory se rvices
Process interrupts _(!.!P~L=-0:=.L.._ _ _ _ _-'
PL 1 System interrupts (ch_~ne Is
L_________
-..J
I
I
Position of an interrupted application program of PL1
Fig. 2. CPU queue structure of ESKO 4 000 PL-Priority Level systems. It is also possible to get a - Statistics describing the time bedump of the data base at any time duhaviour of application programs ring simulation to continue or repeat such as minimum, maximum and mean simulation later. service time and program request losses. Simulating sysiem. This subsystem organizes the even oriented simulation Testing system. Testing systems for process, from which data are gathered the instruction by instruction test by a sampling routine. A data block of single programs are well-known. the length being 4 words consists the The testing system described here actual time, event number and event allows to test computer control syspecific information. These data are stems event by event, especially the buffered in a data buffer of 4 k words control flow through a system of inlength and then stored in a disk meteractiveapplication programs supermory. The simulator processes about visor call by supervisor call. This 300 events per second. will be useful for software system testing. The system designer can deAnalysing system. The analysing sy~ fine "test report points" (the system compUtes statistics of the following prints a report and continues simulatypes from the data gathered: tion), "test interrupt pointsll (the - Statistics that describe the utilisystem prints a report and stop simuzation of the system's resources, in lation) depending on varying conditions; particular CPU utilization (idle time, supervisor state time, program he can also influence the simulation flow by changing the data base. state time). S.F.C ('. -
f-'"
158
D. Rudolf
Simulation Analysis and Testing of Computer Control Systems
ficient is much stronger than the dependence on the kind of distribution. - The possibility to note more than one request at a time can also be of importance for the system behaviour. - Systems with high CPU utilization are better organized in a cyclic way than interrupt oriented.
variation coefficient." 1
Fig. 3. state graph of application programs RESULTS There were two computer control systems investigated: An hypothetic one to verify the correctness of the simUlation program and obtain some basic results concerning information about the behaviour of software systems and a computer control system implemented .in practice; the process controlled is a coal-bunker filling process. com uter control s stem. e app ca on so ware cons s s of twenty independent application programs of equal realization time. They are assigned to the four priority levels five programs on each level. All twenty programs are activated by the same interrupt with a stochasti~ interarrival time. It is easy to calculate the CPU idle time and general request losses as functions of the arrival rate supposing periodical activation. Figures 4, 5 and 6 show these theoretical results in comparison with simulation results using different distributions of interarrival time (Fig. 4), different :(larameters of the same distribution lFig. 5) and the possibility to consider one or two requests for each program at a time (Fig. 6). It can be ooncluded that - the influence of the variation co~
normal
50
11crit
Fig. 4. CPU idle time as function of interrupt rate for different distributions
normal distribution
50
variation coefficient
7tcrit
l\.
Fig. 5. CPU idle time as function of interrupt rate, different variation coefficients
Computer control systems
159
time percentage amounting to about 99 per cent. There is an essential dissemblance between CPU speed and memory utilization.
D. Rudolf
100 normal distribution variation coefficient El
1,0
ti = Number
of program pxecutrons Number of process events
number of poss',ble request notes 1
50
ProQram 4
t---------......:...~~!..!...!!L--
0,5 Program 2 Program '3 Program 1
ltcr',t
Fig. 6. CPU idle time as function of interrupt rate,one or two requests possible at a time Coal-bunker filling process. The application software consists mainly of five application programs controlling the process, which are closely interacting. The prooess can be described by a oyclic process event table with events occurring if the oontent of a bunker reaches a level of nearly 0, 50 or 100 per cent. Investigations were made to find out CPU idle time and program execution factors as functions of average prooess event (interrupt) rate. The results for periodic activation are i~ dicated in F~ 7 and 8. A program
100
200
Fig. 8. Program execution factors as function of interrupt rate CONCLUSIONS The suitability of modelling and simUlation of analyse and test computer control systems, particularly the software, at early stages of design can be concluded. The model presented is based on a specific control computer system. There is a nessecity to implement a simulation language for structured and interactive processes in complex control systems including mass storages and multiprocessing to increase the adaptivility of models and simulation programs to varying computer systems and user requirements. REFEREnCES
.... 98,S
......
........ . 1' ......
theoret,cal
..........
98+------r----~------+-~
100
200
300 71 [h -1]
Fig. 7. CPU idle time as function of interrupt rate system deadlock is the reason for the sudden increase of CPU idle time at a process event rate "A = 156 h- 1 • In this case two programs prevent themselves and others from execution and their program execution factors drop down to zero. The system can never perform its task. A rather surprising fact was the high CPU idle
Risak, V. (1971). Simulation von Digitalrechnern. Computer Monographien 6. Carl Hanser Verlag, MUnchen ROBOTRON 4000 (1973). Systemunterlagen-D okument at ion. VEB Robotron, Zentrum fUr Forschung und Technik, Dresden Rudolf, D. (1979). Simulative Analyse und Testung von ProzeDrechneranwendungssystemen. Arbeitsmaterial der Technischen Hochschule Ilmenau Yourdon, E. (1972). Design of On-line Computer Systems. Prentice Hall, Inc., Englewood Cliffs, New Jersey.