|
|
|
Synchronization of diverse media |
Program development system, method for developing programs and storage medium storing programs for development of programs6467078
Abstract
There is disclosed a program development system, a method for developing programs and a storage medium storing programs for development of programs by which the reduction in development periods of a program to be incorporated into a real time control system and the improvement of qualities are realized. A program development system comprises a state transition storing section to store a state transition matrix, a processing time storing section to store processing time required for an action described in each cell in the state transition matrix, and a simulator to obtain processing time required for a simulation of operations of a system by accumulating events inputted sequentially and time information corresponding to a cell specified sequentially by a state inputted as an initial state or a state subsequent to transition described in each cell.
Claims
What is claimed is:
1. A program development system comprising:
a state transition matrix storing section having two or more cells designated by a state taken by a system for which a program is developed and by an event being a stimulus from the outside or inside of said system, and storing a state transition matrix describing contents of processing to be performed by said system or a state subsequent to transition;
a time information storing section to store time information corresponding to each cell in said state transition matrix; and
a simulator to obtain processing time required for a simulation of operations of said system by accumulating events inputted sequentially and time information corresponding to a cell sequentially designated by a state inputted as an initial state and by a state subsequent to transition.
2. The program development system according to claim 1, wherein it is provided with an inputting section to detect the designation of any of indication positions each corresponding,to two or more events or states constituting said state transition matrix displayed in the display section and to input said positional information about said indication positions into said simulator and wherein said simulator comprises an analysis section to convert positional information inputted by said inputting section to an event code or state code corresponding to said display section, a state storing section to store a state corresponding to said state code or a state subsequent to transition described in each cell, a time accumulating section to accumulate said time information, and a state transition judging section to store a state corresponding to said state code, as said initial state, to said state storing section and to decide a corresponding cell based on an event corresponding to said event code and a state stored in said state storing section and by referring to a state transition matrix read from said state transition matrix storing section and, after reading time information corresponding to the decided cell, to store it to said time accumulating section, and further after reading the state subsequent to transition described in said decided cell, to store it to said state storing section.
3. The program development system according to claim 1, wherein it is provided with an event inputting section to input said initial state and a test script file describing timing of occurrence of each event described in said state transition matrix or timing in operations of constituting factors of said system to be performed to specifications to said simulator and wherein said simulator comprises an event analysis section to create an event inputting sequence obtained by re-arranging, in order of occurrence time, two or more events in a test script file inputted by said event inputting section, a state storing section to store said initial state or a state subsequent to transition described in each cell, a time accumulating section to accumulate said time information, and a state transition judging section to store said initial state into a state storing section and to judge a cell based on an event to be captured, in order of an earlier time, from said event inputting sequence and the state stored in said state storing section and by referring to a state transition matrix read from said state transition matrix storing section and, after reading time information corresponding to the decided cell from said time information storing section, to accumulate it in said time accumulating section and, after reading a state subsequent to transition described in the decided cell from said state transition matrix storing section, to store it to said state storing section.
4. The program development system according to claim 3, wherein it has a test script file creating section to create said test script file from history data of execution of the simulation performed by said simulator based on said initial state inputted by manipulating an operation section and said two or more events.
5. The program development system according to claim 3, wherein said test script file is in a timing chart format, text format or message sequence chart format.
6. The program development system according to claim 1, wherein said simulator is provided with a time comparison section adapted to subtract accumulated time being currently stored in said time accumulating section from occurrence time of said event and, if a positive result is obtained by the subtraction, to add the subtraction result, as a differential time, which is a difference between processing time required for instructions for processing of operations of peripheral devices from a control section constituting said system and processing time required for operations of peripheral devices to be performed in accordance with said processing instructions to the accumulated time being currently stored in said time accumulating section.
7. The program development system according to claim 1, wherein said state transition matrix storing section stores a state transition matrix of operations of a control section constituting said system and a state transition matrix of operations of peripheral devices controlled by said control section and wherein said time information storing section stores time information about operations of said control section and time information about operations of said peripheral devices, and wherein said simulator is composed of a first simulator to accumulate time information about operations of said control section and a second simulator to accumulate time information about operations of said peripheral devices independently of said first simulator.
8. The program development system according to claim 1, wherein it is provided with a generator to create a source program written in a programming language to be incorporated into said system based on said state transition matrix, a compiler to convert said source program to an object program written in a machine language, a first calculating section to calculate time information corresponding to each cell by multiplying an operational speed of said control section constituting said system by code numbers of a machine language constituting said object program corresponding to the processing described in each cell in said state transition matrix or to transition before and after it.
9. The program development system according to claim 1, wherein it is provided with a generator to create a source program written in a programming language to be incorporated into said system based on said state transition matrix, a compiler to convert said source program to an object program written in a machine language, an In-Circuit emulator or a code simulator adapted to execute said object program to allow processing of almost the same as actual operations of said system, and a second calculating section to calculate time information corresponding to each cell in said state transition matrix based on execution time obtained by the execution of said object program by said In-Circuit emulator or said code simulator.
10. The program development system according to claim 9, wherein said time information storing section is composed of, at least two out of a first time information storing section to store time information inputted by manipulating said control section corresponding to each cell in said state transition matrix, a second time information storing section to store time information calculated by said first calculating section corresponding to each cell in said state transition matrix, or a third time information storing section to store time information calculated by said second calculating section corresponding to each cell in said state transition matrix, and a comparison section adapted to said simulator to compare accumulated results obtained by accumulating the corresponding time information at the time of simulation based on time information stored in at least two out of said time information storing sections 1 to 3.
11. The program development system according to claim 1, wherein said time information storing section or said first time information storing section stores time information as values with a certain latitude or variables in accordance with a permissible range in specifications of said system and wherein said simulator is adapted to read the maximum value, minimum value, average values or values randomly selected out of said values with a certain latitude when time information corresponding to a specified cell is read from said time information storing section or said first time information storing section or to change the time information to be accumulated in accordance with said variables.
12. The program development system according to claim 1, wherein said time information is processing time required for processing described in a corresponding cell.
13. The program development system according to claim 12, wherein said time information consists of said processing time and overhead time required for transition from a state or a processing to another state or another processing.
14. The program development system according to claim 13, wherein said overhead time i s uniform o r varies depending on each cell or each transition.
15. A method for developing a program comprising the steps of:
employing a state transition matrix storing section having two or more cells designated by a state taken by a system for which a program is developed and by an event being a stimulus from the outside or inside of said system, and storing a state transition matrix describing contents of processing to be performed by said system or a state subsequent to transition;
employing a time information storing section to store time information corresponding to each cell in said state transition matrix; and
obtaining processing time required for a simulation of operations of said system by accumulating events inputted sequentially and time information corresponding to a cell sequentially designated by a state inputted as an initial state and by a state subsequent to transition.
16. The method of developing a program according to claim 15, comprising the steps of:
employing an inputting section to detect the designation of any of indication positions each corresponding to two or more events or states constituting said state transition matrix displayed in the display section and to input said positional information about said indication positions into said simulator;
converting positional information inputted by said inputting section to an event code or state code corresponding to the display position;
storing a state corresponding said state code as said initial state to a state storing section;
deciding a cell based on an event corresponding to said event code and a state stored in said state storing section and by referring to a state transition matrix read from said state transition storing section;
reading time information corresponding to said decided cell from said time information storing section and accumulating it in the time accumulating section; and
reading a state subsequent to transition described in said decided cell from said state transition matrix storing section and of storing it to said state storing section.
17. The method for developing a program according to claim 15, comprising the steps of:
employing an event inputting section to input said initial state and a test script file describing timing of occurrence of each event described in said state transition matrix or timing in operations of constituting factors of said system to be performed to specifications;
creating an event inputting sequence obtained by re-arranging, in order of occurrence time, two or more events in a test script file inputted by said event inputting section;
storing said initial state to a state storing section;
deciding a corresponding cell based on an event captured in order of an earlier time from said event inputting sequence and a state stored in said state storing section and by referring to a state transition matrix read from said state transition matrix storing section;
reading time information corresponding to said decided cell from said time information storing section and accumulating it from a time accumulating section; and
reading a state subsequent transition described in said decided cell from said state transition matrix storing section and storing it to said state storing section.
18. The method for developing a program according to claim 17, comprising the step of creating said test script file from history data of execution of the simulation performed by said simulator based on said initial state inputted by manipulating an operation section and said two or more events.
19. The method for developing a program according to claim 17 comprising the step of using said test script file being in a timing chart format, in a text file format or in a message sequence chart format.
20. The method for developing a program according to claim 15 comprising the steps of subtracting accumulated time being currently stored in said time accumulating section from occurrence time of said event and, if a positive result is obtained by the subtraction, and of adding the subtraction result, as a differential time, which is a difference between processing time required for instructions for processing of operations of peripheral devices from a control section constituting said system and processing time required for operations of peripheral devices to be performed in accordance with said processing instructions to the accumulated time being currently stored in said time accumulating section.
21. The method for developing a program according to claim 15 comprising the steps of storing a state transition matrix of operations of a control section constituting said system and a state transition matrix of operations of peripheral devices controlled by said control section to said state transition matrix storing section, storing time information about operations of said control section and time information about operations of said peripheral devices to said time information storing section, accumulating time information about operations of said control section and accumulating time information about operations of said peripheral devices independently of said steps.
22. The method for developing a program according to claim 15 comprising the steps of creating a source program written in a programming language to be incorporated into said system based on said state transition matrix, converting said source program to an object program written in a machine language, and calculating time information corresponding to each cell by multiplying an operational speed of said control section constituting said system by code numbers of a machine language constituting said object program corresponding to the processing described in each cell in said state transition matrix or to transition before and after it.
23. The method for developing a program according to claim 15 comprising the steps of creating a source program written in a programming language to be incorporated into said system based on said state transition matrix, converting said source program to an object program written in a machine language, executing said object program and calculating time information corresponding to each cell in said state transition matrix based on execution time obtained by the execution of said object program.
24. The method for developing a program according to claim 23 comprising the steps of employing said time information storing section composed of, at least two out of a first time information storing section to store time information inputted by manipulating said control section corresponding to each cell in said state transition matrix, a second time information storing section to store time information calculated by said first calculating section corresponding to each cell in said state transition matrix, or a third time information storing section to store time information calculated by said second calculating section corresponding to each cell in said state transition matrix, and comparing accumulated results obtained by accumulating the corresponding time information at the time of simulation based on time information stored in at least two out of said time information storing sections 1 to 3.
25. The method for developing a program according to claim 15 comprising the steps of employing said time information storing section or said first time information storing section which stores time information as values with a certain latitude or variables in accordance with a permissible range in specifications of said system, reading the maximum value, minimum value, average values or values randomly selected out of said values with a certain latitude when time information corresponding to a specified cell is read from said time information storing section or said first time information storing section or changing the time information to be accumulated in accordance with said variables.
26. The method for developing a program according to claim 15 comprising the step of using said time information which is processing time required for execution of processing described in. a corresponding cell.
27. The method for developing a program according to claim 26 comprising the step of using said time information which is overhead time required for transition from a state or a processing to another state or another processing.
28. The method for developing a program according to claim 27 comprising the step of using said overhead time which is uniform or varies depending on each cell or each transition.
29. A storage medium storing programs for development of programs to have a computer achieve functions described in claim 1.
30. A storage medium storing programs for development of programs to have a computer achieve functions described in claim 15.
Description
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a program development system, a method for developing programs and a storage medium storing programs for development of programs and more particularly to a program development system, a method for developing programs and a storage medium storing programs for development of programs to be suitably used for developing programs that can be incorporated into a real time control system such as various electronic apparatus including a facsimile, copying machine as well as a monitoring/controlling system including power facilities, which has to be controlled in real time.
2. Description of the Related Art:
A real time control system is required to carry out processing of an event which is a stimulus from the outside and inside of the system including reception of various signals, of a state which is a condition held by the system including a standby state to receive signals, of a combination of the above event and state and of a lot of actions to be executed by the system when a specific event occurs in a specified state. As one of approaches for developing programs to be incorporated into such a real time control system, a method using a State Transition Matrix is known. The State Transition Matrix is a two-dimensional matrix wherein an event or state is assigned to a string or a row and both the actions corresponding to a cell which is a point of intersection of an event and a state and the state subsequent to transition taking place after the action are arranged. Though the current real time control system has recently been made large-scale and increased in complexity, this method for developing programs allows basic design of the system by even a less experienced person, resulting in labor saving and acceleration of developing periods.
FIG. 22 is a block diagram showing an example of electrical configurations of a conventional program development system disclosed in Japanese Laid-open Patent Application No. Hei9-325952.
The program development system in this example is approximately composed of a definition matrix inputting section 1 to input information about abstract mechanical definition which defines, by using a hierachically related state transition matrix, an operation of a system including activity that means processing performed continuously during time required for processing in each state and in a current state, a storing section 2 to store the information about the inputted abstract mechanical definition as an abstract mechanical definition matrix, a state hierarchy extracting section 3 used to extract a hierarchical structure of a state from the abstract mechanical definition matrix read from the storing section 2, a forecast processing time calculating section 4 used to calculate a forecast processing time assigned to its lower state in each state in the abstract mechanical definition matrix and to judge whether or not the calculated result exceeds the forecast processing time of the state to be handled at present, and a warning display section 5 used to check the calculated result and to issue a warning if a total processing time required in the lower state exceeds that required in the upper state.
This configurations allows, prior to actual operations of a system, a verification, by using a combination of fragmentary information about processing time, that an operation is carried out without delay.
In the conventional program development system, the forecast processing time calculating section 4 is used to calculate the forecast processing time assigned to its lower state in each state in the abstract mechanical definition matrix and the warning display section 5 is employed to issue a warning if the total time required for processing in the lower state exceeds that in the upper state being handled at present.
However, the processing time is ideal time based on specifications of a real time control system and no consideration is given to a variety of actually occurring events.
Accordingly, when a program developed on the basis of such an abstract mechanical definition matrix is incorporated into a system, if a malfunction that the system is not actuated to specifications occurs, it is necessary to retrace steps to the extent that even basic design is amended, causing development periods longer. This is one disadvantage of the conventional system.
Another disadvantage of the conventional system is that, the development time is usually restricted within a limit and if such a malfunction as described above occurs at the last stage of the development, retracing steps to the extent that basic design is amended is not allowed and there would be no way but choose rough and temporizing amendments, thus degrading the quality of the system
SUMMARY OF THE INVENTION
In view of the above, it is an object of the present invention to provide a program development system, a method for developing programs and a storage medium storing programs for development of programs by which the reduction in development periods of a program to be incorporated into a real time control system and the improvement of qualities are realized.
According to a first aspect of the present invention, there is provided a program development system comprising:
a state transition matrix storing section having two or more cells designated by a state taken by a system for which a program is developed and by an event being a stimulus from the outside or inside of the system, and storing a state transition matrix describing contents of processing to be performed by the system or a state subsequent to transition;
a time information storing section to store time information corresponding to each cell in the state transition matrix; and
a simulator to obtain processing time required for a simulation of operations of the system by accumulating events inputted sequentially and time information corresponding to a cell sequentially designated by a state inputted as an initial state and by a state subsequent to transition.
In the foregoing, a preferable mode is one wherein the program development system is provided with an inputting section to detect the designation of any of indication positions each corresponding to two or more events or states constituting the state transition matrix displayed in the display section and to input the positional information about the indication positions into the simulator and wherein the simulator comprises an analysis section to convert positional information inputted by the inputting section to an event code or state code corresponding to the display section, a state storing section to store a state corresponding to the state code or a state subsequent to transition described in each cell, a time accumulating section to accumulate the time information, and a state transition judging section to store a state corresponding to the state code, as the initial state, to the state storing section and to decide a corresponding cell based on an event corresponding to the event code and a state stored in the state storing section and by referring to a state transition matrix read from the state transition matrix storing section and, after reading time information corresponding to the decided cell, to store it to the time accumulating section, and further after reading the state subsequent to transition described in the decided cell, to store it to the state storing section.
Also, a preferable mode is one wherein the program development system is provided with an event inputting section to input the initial state and a test script file describing timing of occurrence of each event described in the state transition matrix or timing in operations of constituting factors of the system to be performed to specifications to the simulator and wherein the simulator comprises an event analysis section to create an event inputting sequence obtained by re-arranging, in order of occurrence time, two or more events in a test script file inputted by the event inputting section, a state storing section to store the initial state or a state subsequent to transition described in each cell, a time accumulating section to accumulate the time information, and a state transition judging section to store the initial state into a state storing section and to judge a cell based on an event to be captured, in order of an earlier time, from the event inputting sequence and the state stored in the state storing section and by referring to a state transition matrix read from the state transition matrix storing section and, after reading time information corresponding to the decided cell from the time information storing section, to accumulate it in the time accumulating section and, after reading a state subsequent to transition described in the decided cell from the state transition matrix storing section, to store it to the state storing section.
Also, a preferable mode is one wherein the program development system has a test script file creating section to create the test script file from history data of execution of the simulation performed by the simulator based on the initial state inputted by manipulating an operation section and two or more events.
Also, a preferable mode is one wherein the simulator is provided with a time comparison section adapted to subtract accumulated time being currently stored in the time accumulating section from occurrence time of the event and, if a positive result is obtained by the subtraction, to add the subtraction result, as a differential time, which is a difference between processing time required for instructions for processing of operations of peripheral devices from a control section constituting the system and processing time required for operations of peripheral devices to be performed in accordance with the processing instructions to the accumulated time being currently stored in the time accumulating section.
Also, a preferable mode is one wherein the state transition matrix storing section stores a state transition matrix of operations of a control section constituting the system and a state transition matrix of operations of peripheral devices controlled by the control section and wherein the time information storing section stores time information about operations of the control section and time information about operations of the peripheral devices, and wherein the simulator is composed of a first simulator to accumulate time information about operations of the control section and a second simulator to accumulate time information about operations of the peripheral devices independently of the first simulator.
Also, a preferable mode is one wherein the program development system is provided with a generator to create a source program written in a programming language to be incorporated into the system based on the state transition matrix, a compiler to convert the source program to an object program written in a machine language, a first calculating section to calculate time information corresponding to each cell by multiplying an operational speed of the control section constituting the system by code numbers of a machine language constituting the object program corresponding to the processing described in each cell in the state transition matrix or to transition before and after it.
Also, a preferable mode is one wherein the program development system is provided with a generator to create a source program written in a programming language to be incorporated into the system based on the state transition matrix, a compiler to convert the source program to an object program written in a machine language, an In-Circuit emulator or a code simulator adapted to execute the object program to allow processing of almost the same as actual operations of the system, and a second calculating section to calculate time information corresponding to each cell in the state transition matrix based on execution time obtained by the execution of the object program by the In-Circuit emulator or the code simulator.
Also, a preferable mode is one wherein the time information storing section is composed of at least two out of a first time information storing section to store time information inputted by manipulating the control section corresponding to each cell in the state transition matrix, a second time information storing section to store time information calculated by the first calculating section corresponding to each cell in the state transition matrix, or a third time information storing section to store time information calculated by the second calculating section corresponding to each cell in the state transition matrix, and a comparison section adapted to the simulator to compare accumulated results obtained by accumulating the corresponding time information at the time of simulation based on time information stored in at least two out of the time information storing sections 1 to 3.
Furthermore, a preferable mode is one wherein the time information storing section or the first time information storing section stores time information as values with a certain latitude or variables in accordance with a permissible range in specifications of the system and wherein the simulator is adapted to read the maximum value, minimum value, average values or values randomly selected out of the values with a certain latitude when time information corresponding to a specified cell is read from the time information storing section or the first time information storing section or to change the time information to be accumulated in accordance with the variables.
In the foregoing, it is preferable that the test script file is in a timing chart format, text format or message sequence chart format.
Also, it is preferable that the time information is processing time required for processing described in a corresponding cell.
Also, a preferable mode is one wherein the time information consists of the processing time and overhead time required for transition from a state or a processing to another state or another processing.
Furthermore, a preferable mode is one wherein the overhead time is uniform or varies depending on each cell or each transition.
According to a second aspect of the present invention, there is provided a method for developing a program comprising:
employing a state transition matrix storing section having two or more cells designated by a state taken by a system for which a program is developed and by an event being a stimulus from the outside or inside of the system, and storing a state transition matrix describing contents of processing to be performed by the system or a state subsequent to transition;
employing a time information storing section to store time information corresponding to each cell in the state transition matrix; and
obtaining processing time required for a simulation of operations of the system by accumulating events inputted sequentially and time information corresponding to a cell sequentially designated by a state inputted as an initial state and by a state subsequent to transition.
In the above-mentioned second aspect, a preferable mode is one that wherein comprises the steps of:
employing an inputting section to detect the designation of any of indication positions each corresponding to two or more events or states constituting the state transition matrix displayed in the display section and to input the positional information about the indication positions into the simulator;
converting positional information inputted by the inputting section to an event code or state code corresponding to the display position;
storing a state corresponding the state code as the initial state to a state storing section;
deciding a cell based on an event corresponding to the event code and a state stored in the state storing section and by referring to a state transition matrix read from the state transition storing section;
reading time information corresponding to the decided cell from the time information storing section and accumulating it in the time accumulating section; and
reading a state subsequent to transition described in the decided cell from the state transition matrix storing section and of storing it to the state storing section.
Also, a preferable mode is one that wherein comprises the steps of:
employing an event inputting section to input the initial state and a test script file describing timing of occurrence of each event described in the state transition matrix or timing in operations of constituting factors of the system to be performed to specifications;
creating an event inputting sequence obtained by re-arranging, in order of occurrence time, two or more events in a test script file inputted by the event inputting section;
storing the initial state to a state storing section;
deciding a corresponding cell based on an event captured in order of an earlier time from the event inputting sequence and a state stored in the state storing section and by referring to a state transition matrix read from the state transition matrix storing section;
reading time information corresponding to the decided cell from the time information storing section and accumulating it from a time accumulating section; and
reading a state subsequent transition described in the decided cell from the state transition matrix storing section and storing it to the state storing section.
Also, a preferable mode is one that wherein comprises the step of creating the test script file from history data of execution of the simulation performed by the simulator based on the initial state inputted by manipulating an operation section and two or more events.
Also, a preferable mode is one that wherein comprises the steps of subtracting accumulated time being currently stored in the time accumulating section from occurrence time of the event and, if a positive result is obtained by the subtraction, and of adding the subtraction result, as a differential time, which is a difference between processing time required for instructions for processing of operations of peripheral devices from a control section constituting the system and processing time required for operations of peripheral devices to be performed in accordance with the processing instructions to the accumulated time being currently stored in the time accumulating section.
Also, a preferable mode is one that wherein comprises the steps of storing a state transition matrix of operations of a control section constituting the system and a state transition matrix of operations of peripheral devices controlled by the control section to the state transition matrix storing section, storing time information about operations of the control section and time information about operations of the peripheral devices to the time information storing section, accumulating time information about operations of the control section and accumulating time information about operations of the peripheral devices independently of the steps.
Also, a preferable mode is one that wherein comprises the steps of creating a source program written in a programming language to be incorporated into the system based on the state transition matrix, converting the source program to an object program written in a machine language, and calculating time information corresponding to each cell by multiplying an operational speed of the control section constituting the system by code numbers of a machine language constituting the object program corresponding to the processing described in each cell in the state transition matrix or to transition before and after it.
Also, a preferable mode is one that wherein comprises the steps of creating a source program written in a programming language to be incorporated into the system based on the state transition matrix, converting the source program to an object program written in a machine language, executing the object program and calculating time information corresponding to each cell in the state transition matrix based on execution time obtained by the execution of the object program.
Also, a preferable mode is one that wherein comprises the steps of employing the time information storing section composed of at least two out of a first time information storing section to store time information inputted by manipulating the control section corresponding to each cell in the state transition matrix, a second time information storing section to store time information calculated by the first calculating section corresponding to each cell in the state transition matrix, or a third time information storing section to store time information calculated by the second calculating section corresponding to each cell in the state transition matrix, and comparing accumulated results obtained by accumulating the corresponding time information at the time of simulation based on time information stored in at least two out of the time information storing sections 1 to 3.
Also, a preferable mode is one that wherein comprises the steps of employing the time information storing section or the first time information storing section which stores time information as values with a certain latitude or variables in accordance with a permissible range in specifications of the system, reading the maximum value, minimum value, average values or values randomly selected out of the values with a certain latitude when time information corresponding to a specified cell is read from the time information storing section or the first time information storing section or changing the time information to be accumulated in accordance with the variables.
Also, a preferable mode is one that wherein comprises the step of using the test script file being in a timing chart format, in a text file format or in a message sequence chart format.
Also, a preferable mode is one that wherein comprises a step of using the time information which is processing time required for the execution of processing described in a corresponding cell.
Also, a preferable mode is one that wherein comprises the step of using the time information which is overhead time required for transition from a state or a processing to another state or another processing.
Also, a preferable mode is one that wherein comprises the step of using the overhead time which is uniform or varies depending on each cell or each transition.
According to a third aspect of the present invention, there is provided a storage medium storing programs for development of programs to have a computer achieve functions described in the first aspect and the second aspect.
BRIEF DESCRIPTION OF THE DRAWING
The above and other objects, advantages and features of the present invention will be more apparent from the following description taken in conjunction with the accompanying drawings in which:
FIG. 1 is a block diagram showing electrical configurations of a program development system shown in a first embodiment of the present invention;
FIG. 2 is a schematic diagram illustrating a rough configuration of a prepaid card selling machine for which a program is developed;
FIG. 3 is one of examples of a state transition matrix for operations of CPU constituting the above prepaid card selling machine;
FIG. 4 shows one example of a simulation mode screen displayed in a display section constituting a man-machine interface of the first embodiment;
FIG. 5 is a flow chart showing operations of a simulator of the first embodiment;
FIG. 6 is a block diagram showing electrical configurations of a program development system shown in a second embodiment of the present invention;
FIG. 7 is one of examples of a test script file in the text file form to be used for a simulation in the second embodiment of the present invention;
FIG. 8 shows a flow chart illustrating operations of the simulations in the second embodiment of the present invention.
FIG. 9 is one of examples of an event inputting sequence created from the test script file shown in FIG. 7.
FIG. 10 shows a timing chart of one of examples of the simulation results in the second embodiment of the present invention;
FIG. 11 shows one of examples of a state transition state of operations of a magnetic head constituting a prepaid card selling machine for which a program is developed in the third embodiment of the present invention;
FIG. 12 shows one of examples of a test script file in a timing chart format to be used for the simulation in the third embodiment;
FIG. 13 shows one of examples of the test script file in a timing chart format to be used for the simulation in the third embodiment;
FIG. 14 illustrates one of examples of configurations of an overhead storing section of the third embodiment;
FIG. 15 shows a flow chart showing operations of a simulator of the same embodiment;
FIG. 16 shows a timing chart showing one of examples of simulation results in the same embodiment;
FIG. 17 is a block diagram showing an electrical configuration of the program development system of a fourth embodiment of the present invention;
FIG. 18 is a block diagram showing an electrical configuration of the program development system of a fifth embodiment of the present invention;
FIG. 19 is a block diagram showing an electrical configuration of the program development system of a sixth embodiment of the present invention;
FIG. 20 is a block diagram illustrating an electrical configuration of the program development system of a seventh embodiment of the present invention;
FIG. 21 shows one of examples of a test script file in a message sequence chart format to be used for a simulation in the second embodiment of the present invention; and
FIG. 22 is a block diagram showing an example of electrical configurations of a conventional program development system.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Best modes of carrying out the present invention will be described in further detail using various embodiments with reference to the accompanying drawings.
First Embodiment
FIG. 1 is a block diagram showing electrical configurations of a program development system shown in a first embodiment of the present invention.
The program development system in this embodiment, as depicted in FIG. 1, approximately comprises a man-machine interface 11, an editor 12, a state transition matrix storing section 13, a processing time storing section 14, a generator 15, a program storing section 16, an inputting section 17, and a simulator 18.
The man-machine interface 11 is composed of a display section 11a, a mouse 11b and a keyboard 11c. It is used to input data (state, event, action, state subsequent to transition) required for an operator to create a state transition matrix by referring to a display contents of the display section 11a or by operating the mouse 11b or the keyboard 11c and/or to direct inputting of an event, in order to cause the simulator 18 to perform a simulation for every event based on the state transition matrix of a real time control system designed by a state transition matrix, by moving a cursor using a cursor key of the mouse 11b or the keyboard 11c to a display area of an event in the state transition matrix displayed in the display section 11a and by clicking or pressing a return key down. The simulation results (state subsequent to transition, accumulated time and the like) fed by the simulator 18 are displayed in the display section 11a. The processing time represents time required for an action described in each cell.
The editor 12 is used to create and edit the state transition matrix based on a state, event, action, state subsequent to transition, accumulated time and the like inputted using the man-machine interface 11 and also to store data on the state transition matrix and the processing time in the corresponding state transition matrix storing section 13 and processing time storing section 14. Both the state transition matrix storing section 13 and the processing time storing section 14 are composed of a storage medium having a large-scale memory capacity such as semiconductor memory including RAM, FD (floppy disk), HD (hard disk ) and the like. Data on the state transition matrix is stored in the state transition matrix storing section 13 and processing time is stored in the processing time storing section 14.
The generator 15 is adapted to automatically generate a program (source program) to be incorporated into a real time control system described in a programming language such as C language (trade mark name) based on a state transition matrix read out from the state transition matrix storing section 13, and the program storing section 16 stores the generated program. The program storing section 16 is composed of a storage medium having a large-scale capacity such as semiconductor memory including RAM, FD or HD and stores the source program therein.
The inputting section 17 is adapted to detect a position of a cursor at the time when a left button of a mouse is clicked or a return key is pressed down by an operator after the cursor is moved by using a cursor key of the mouse 11b or the keyboard 11c to a display area of any event or state in the state transition matrix displayed in the display section la and feed the information about the position to an analysis section 18a. That is, the inputting section 17 in this embodiment functions as a position detecting section for an event or state.
The simulator 18 approximately comprises the analysis section 18a, a state transition judging section 18b, a time accumulating section 18c and a state storing section 18d. The analysis section 18a is adapted to convert the information about the position fed by the inputting section 17 to event or state codes corresponding to the position and to feed the resulting codes to the state storing section 18d. That is, the analysis section 18a functions as a section to convert the positional information to event/state codes. The state transition judging section 18b is used to control each constitutional factor in the simulator 18 and to set a state corresponding to the state code fed by the analysis section 18a, as an initialized state, to the state storing section 18d and to determine a corresponding cell, based on an event corresponding to the event code fed by the analysis section 18a and on a state stored in the state storing section 18d, by referring to the state transition matrix read out from the state transition matrix storing section 13. Moreover, the state transition judging section 18b is used to accumulate processing time corresponding to actions to be processed by the determined cell in the time accumulating section 18c by reading out it from the processing time storing section 14. Furthermore, the state transition judging section 18b is used to read a state subsequent to transition described in the cell determined by itself and to store it in the state storing section 18d, and to feed, every time one simulation is completed, accumulated time stored in the time accumulating section 18c and the state subsequent to transition stored in the state storing section 18d to the man-machine interface 11. The time accumulating section 18c and the state storing section 18d are composed of semiconductor memory such as RAM and store accumulated time and a state subsequent to transition respectively.
Operations of the program development device having configurations described above are further described in detail. A program to be developed by the program development device is presumed to be a program to be incorporated into a prepaid card selling machine as shown in FIG. 2. The prepaid card here represents an approximately name-card-sized plastic card which can be purchased at a predetermined price and can be used to buy goods, passenger cards and the like as a substitute for cash.
The prepaid card selling machine approximately comprises a control section 21 to control a machinery section 22 and an operation and display section 23, the machinery section 22 to issue the prepaid card, the operation and display section 23 which is operated by a purchaser of the prepaid card for buying and is referred to its displaying portion. The control section 21 approximately comprises a CPU (central processing unit) 24, ROM 25 to store the above programs, RAM 26 used by the CPU 24 to execute programs, an input port 27 to feed a detection signal or an interrupt signal supplied by each constitutional factor constituting the machinery section 22 and the operation and display section 23 to the CPU 24, and an output port 28 used by the machinery section 22 to feed a control signal to a motor 35 and 37 constituting the machinery section 22.
The machinery section 22 is composed of a stacker 29, a card taking-out mechanism 30, a card transfer mechanism 31, sensors 32 and 33, a magnetic head 34a for writing magnetic data, and a magnetic head 34b for reading magnetic data. Operations of the machinery section 22 are as follows.
When a purchaser feeds cash into a cash supply port (not shown) of the operation and display section 23 and presses down a card-type designating button (not shown) and a card-issue designating button (not shown), a motor constituting, together with a roller and a belt, the card taking-out mechanism 30 is driven and, from a stacker storing two or more prepaid cards 36 with a belt-shaped magnetic stripe having no magnetic data (to be called a "raw card"), one raw card 36 is taken out and transferred in the downward direction as shown in FIG. 2. Then, when the raw card 36 is detected by a sensor 32 composed of a photo coupler and the like, a motor 35 is stopped and a motor 37 constituting, together with a roller and a belt, the card transfer mechanism 31 is driven to transfer the raw card 36 in a transfer path in the right direction and a magnetic data containing a purchase amount or a card issuing date is written on the magnetic stripe of the raw card 36 by a magnetic head 34a fitted on the transfer path. In order to check if currently written magnetic data is correct, a prepaid card on which magnetic data has just been written is transferred on the transfer path in the right direction as shown in FIG. 2, and a magnetic head 34b reads the magnetic data from the prepaid card. If the read data is judged to be correct, after the prepaid card is transferred further in the right direction on the transfer path as shown in FIG. 2 and is detected by a sensor 33 composed of a photo coupler, the card is ejected from the card issuing port (not shown) and the motor 37 is stopped simultaneously. The operations of the machinery section 22 described above are controlled by the CPU 24, based on a program stored in ROM 25, through the input port 27 and the output port 28.
Let it be supposed that specifications of the prepaid card selling machine describe that it should take 15 ms to issue one prepaid card, processing time required for operations in the card taking-out mechanism 30 is 5 ms and processing time required for operations in the card transfer mechanism 31 is 10 ms. In addition, let it be supposed that one prepaid card is issued in one operation.
In order to create a state transition matrix as shown in FIG. 3, an operator inputs necessary data (state, event, action, state subsequent to transition, processing time and the like) by operating the mouse 11b and the keyboard 11c, while referring to a display of the display section 11a constituting the man-machine interface 11, based on specifications of the above prepaid card selling machine. The editor 12, using the above data, creates the state transition matrix as shown in FIG. 3, displays it on the display section 11a constituting the man-machine interface 11 and stores data on the state transition matrix and processing time at a specified area of each of the state transition matrix storing section 13 and the processing time storing section 14.
Referring to FIG. 3, a motor A and a motor B correspond to a motor 35 and a motor 37 shown in FIG. 2 respectively, and a mark S1 and a mark S2 represent a sensor 32 and a sensor 33 in FIG. 2 shown in FIG. 2 respectively. In the uppermost line of the matrix in FIG. 3, the "Motor A" represents that the motor 35 stops being in the standby state to receive an instruction for issuing a prepaid card or the motor 35 is in the driving state (hereinafter referred to as "State 1"); the "Motor B: Under writing" representing that the motor 37 is in the driving state and in the state where magnetic data is being written on the raw card 36 by a magnetic head 34a (hereinafter as "State 2"); the "Motor B: Under reading" representing that the motor 37 is in the driving state and in the state where magnetic data of the prepaid card is being read by the magnetic head 34b (hereinafter as "State 3"); and the "Motor B: S2 standby" representing that the motor 37 is in the driving state and in the standby state to receive a detection signal from the sensor 33 while the prepaid card is ejected from the issuing port (hereinafter as "State 4"). Moreover, the "Motor B" represents that the state is in the upper one in the State 2 to State 4.
In the most left column of the matrix in FIG. 3, the "Card issue request" represents that the issue of the card has been requested by the supply of cash or the pressing-down of a specified button by a purchaser of the card (hereafter as "Event 1"); the "S1:OFF.fwdarw.ON" representing that a detection signal from the sensor 32 has changed from "OFF" to "ON" due to the passage of the raw card 36 through the sensor 32 (hereafter as "Event 2"); the "Writing: OK" representing receipt of a notice that writing of magnetic data consisting of purchasing amounts, an issue date of a card and the like to a magnetic stripe of the raw card 36 by the magnetic head 34a has normally been completed (hereinafter as "Event 3"); the "Writing: NG" representing receipt of a notice that abnormal writing of magnetic data to the raw card 36 by the magnetic head 34a has occurred (hereinafter as "Event 4"); the "Reading: OK" representing receipt of a notice that reading of magnetic data from a prepaid card by the magnetic head 34b has normally been completed (hereinafter as "Event 5"); the "Reading: NG" representing receipt of a notice that abnormal reading of magnetic data from a prepaid card by the magnetic head 34b has occurred (hereinafter as "Event 6"); the "S2: OFF.fwdarw.ON" representing that a detection signal of the sensor 33 has changed from OFF to ON due to the arrival of a prepaid card through the sensor 33 to the card issuing port (hereinafter as "Event 7").
The Event 1 is called a message-type event which represents receipt of an actuating message from other tasks or devices and the Event 2 and Event 7 are called a flag-type event which represents reading of a variable or a change of inputting/outputting. Moreover, the Event 3 to Event 6 are called an interrupt event which represents receipt of an interrupt from the outside.
In the state transition matrix shown in FIG. 3, if a point of intersection of an event and a state, for example, of the State 1 and the Event 2 is represented as a cell (1, 2), contents described by each cell have the following meanings. That is, in the cell (1,1) shown in the matrix in FIG. 3, the "Motor A: ON" represents an action to actuate the motor 35 in order to take out the raw card 36 from the stacker 29, in the standby State 1 to receive an instruction for issuing a prepaid card and in response to the occurrence of the Event 1 of the request for issuing a prepaid card directed by the supply of cash or the pressing-down of a specified button by a purchaser of the card. The numeric values (0.5) represents that time required for processing the above action is 0.5 ms. The reason that a state subsequent to transition is not described is that the operation remains in the present state. i.e., in the State 1.
In the cell (1, 2), the "Motor A: OFF, Motor B: ON, Writing" represents actions to switch a transfer of the raw card 36 from a transfer by use of the card taking-out mechanism 30 to a transfer by use of the card transfer mechanism 31 in response to the occurrence of the Event 2 where a detection signal from the sensor 32 has changed from "OFF" to "ON" due to the passage of the raw card 36 through the sensor 32 and to stop the driving of the motor 35 in order to write magnetic data on the raw card and simultaneously to drive the motor 37 and further to request the magnetic head 34a to write specified magnetic data on the card. Moreover, in the cell (1, 2), the "=>Under writing" represents that the state subsequent to transition is the State 2 and the numeric value (4) shows that total time required for processing a series of the above actions is 4 ms.
In the cell (1, 3) of the matrix in FIG. 3, the mark "/" represents that no action is implemented and no transition of a state takes place therein. The meaning of the mark "/" is the same as in other places in the table and accordingly its description is omitted in other places.
In the cell (2, 1), the "Error Message" represents an action to display a message, on a display device of the operation and display section 23 constituting the prepaid card selling machine, that, in the State 2 where magnetic data is being written on the raw card 36 by the magnetic head 34a, if the Event 1 of a request for further issuing a prepaid card occurs, it is impossible to issue the requested card because only one prepaid card can be issued in one operation as defined in the specifications. In the same cell (2, 1), the symbol "=>-" represents that the operation remains in the present state. i.e., in the State 2. The numeric value (1) shows time required for processing the above actions is 1 ms.
In the cell (2, 3), the "Reading" represents an action to request the magnetic head 34b to read magnetic data of the prepaid card that has just been written to check if the magnetic data that has just been written on the prepaid card is correct, in the State 2 where magnetic data is being written on the raw card 36 by the magnetic head 34a and in response to the occurrence of the Event 3 wherein a notice is given by the magnetic head 34a informing of normal writing of magnetic data. In the cell (2, 3), the "=>Under reading" represents that a state subsequent to transition is the State 3 and the numeric value (1) shows that time required for processing the above action is 1 ms.
In the cell (2, 4), the "Writing" represents an action to request the magnetic head 34a to again write the same magnetic data on the prepaid card which a failure in writing has occurred thereon, in the State 2 wherein magnetic data is being written on the raw card 36 by the magnetic head 34a and in response to the occurrence of the Event 4 wherein a notice has been given by the magnetic head 34a informing of abnormal writing of the magnetic data. In the same cell (2, 4), the symbol"=>-" represents that the operation remains in the present state. i.e., in the State 2. The numeric value (3) shows time required for processing the above actions is 3 ms.
In the cell (2, 5), the "Error Reset, Writing" represents an action to request the magnetic heads 34a and 34b to perform initializations and to again write the same magnetic data on a prepaid card based on a judgement that abnormality has happened in the magnetic heads 34a and 34b, in the State 2 wherein magnetic data is being written on the raw card 36 by the magnetic head 34a, i.e., even in the state requesting the magnetic head 34a to write magnetic data and in the case of the occurrence of the Event 5 wherein a notice is given by the magnetic head 34a informing of normal writing of magnetic data. In the same cell (2, 5), the symbol "=>-" represents that the operation remains in the present state. i.e., in the State 2. The numeric value (4) shows time required for processing the above actions is 4 ms.
In the cell (2, 6), the "Error Reset, Writing" represents an action to request the magnetic heads 34a and 34b to perform initializations and to again write the same magnetic data on a prepaid card based on a judgement that abnormality has occurred in the magnetic heads 34a and 34b, in the State 2 wherein magnetic data is being written on the raw card 36 by the magnetic head 34a, i.e., even in the state requesting the magnetic head 34a to write magnetic data and in the case of the occurrence of the Event 5 wherein a notice is given by the magnetic head 34b informing of abnormal reading of magnetic data from the prepaid card. In the same cell (2, 6), the symbol "=>-" represents that the operation remains in the present state, i.e., in the State 2. The numeric value (4) shows time required for processing the above actions is 4 ms.
In the cell (3, 1), the "Error Message" represents an action to display a message, on a display device of the operation and display section 23 constituting the prepaid card selling machine, that, in the State 3 where magnetic data is being read from the prepaid card:, if the Event 1 of a request for further issuing a prepaid card occurs, it is impossible to issue the requested card because only one prepaid card can be issued in one operation as defined in the specifications. In the same cell (3, 1), the symbol "=>-" represents that the operation remains in the present state, i.e., in the State 3. The numeric value (1) shows time required for processing the above actions is 1 ms.
In the cell (3, 3), the "Error Reset, Reading" represents an action to request the magnetic heads 34a and 34b to perform initializations and to again read the magnetic data from a prepaid card based on a judgement that abnormality has occurred in the magnetic heads 34a and 34b, in the State 3 wherein magnetic data is being read from the prepaid card, i.e., even in the state requesting the magnetic head 34a to read magnetic data and in the case of the occurrence of the Event 3 wherein a notice is given by the magnetic head 34a informing of normal writing of magnetic data on the prepaid card. In the same cell (3, 3), the symbol "=>-" represents that the operation remains in the present state, i.e., in the State 3. The numeric value (2) shows time required for processing the above actions is 2 ms.
In the cell (3, 4), the "Error Reset, Reading" represents an action to request the magnetic heads 34a and 34b to perform initializations and to again read the magnetic data from a prepaid card based on a judgement that abnormality has occurred in the magnetic heads 34a and 34b, in the State 3 wherein magnetic data is being read from the prepaid card, i.e., even in the state requesting the magnetic head 34a to read magnetic data and in the case of the occurrence of the Event 4 wherein a notice is given by the magnetic head 34a informing of abnormal writing of magnetic data on the prepaid card. In the same cell (3, 4), the symbol "=>-" represents that the operation remains in the present state, i.e., in the State 3. The numeric value (2) shows time required for processing the above actions is 2 ms.
In the cell (3, 5), no description of an action and processing time is provided. This is because, in the State 3 wherein magnetic data is being read from a prepaid card, if an Event 5 occurs wherein a notice is supplied by the magnetic head 34b informing of normal reading of magnetic data from the prepaid card, it is possible to judge that magnetic data has normally been written on the prepaid card to be issued, requesting for no action to be executed in this cell and no processing time to be considered. Moreover, in the cell (3, 5), the "=>S2 standby" represents that a state subsequent to transition is the State 4.
In the cell (3, 6), the "Reading" represents an action to request the magnetic head 34b to read magnetic data from a prepaid card which has failed in reading magnetic data, in the State 3 wherein magnetic data is being read from the prepaid card and in response to the occurrence of the Event 6 wherein a notice is given by the magnetic head 34b informing of abnormal reading of magnetic data. In the same cell (3, 6), the symbol "=>-" represents that the operation remains in the present state, i.e., in the State 3. The numeric value (1) shows time required for processing the above actions is 1 ms.
In the cell (4, 7), the "Motor B:OFF" represents an action to stop the driving of the motor 37 in preparation for a request for issuing a next prepaid card, in the standby State 4 to receive a detection signal fed from the sensor 33 during the driving of the motor 37 and in response of the occurrence of the Event 7 wherein a detection signal fed from the sensor 33 has changed from the OFF to ON state due to the arrival of the prepaid card through the sensor 33 to a card issuing port. the "=>Motor A" represents that a state subsequent to transition is the State 1 and the numeric value (0.5) shows that time required for processing the above action is 0.5 ms.
Then, when an operator operates the mouse lib or the keyboard 11c constituting the man-machine interface 11 according to specifications of the above prepaid card selling machine and puts this program development system into a simulation mode in order to perform a simulation for every one event using a simulator 18 based on the above state transition matrix, a simulation mode screen appears on the display section 11a as shown in FIG. 4.
Operations of the inputting section 17 and the simulator 18 as well as steps taken by an operator when processing time required by the CPU 24 for the passage of the raw card 36 through the sensor 33 after the passage through the sensor 32 is obtained are hereinafter described with reference to a flow chart shown in FIG. 5.
An operator moves, using the cursor key of the mouse 11b or keyboard 11c, the cursor to the START area for a simulation displayed on the upper part of the simulation mode screen shown in FIG. 4, clicks the left button of the mouse or presses the return key down and then provides an instruction to the simulator 18 to start the simulation. In response to this instruction, the state transition judging section 18b goes to step SA1 for processing, after clearing stored contents of the time accumulating section 18c to 0 ms, and further to step SA2.
Furthermore, the operator moves the cursor, using the cursor key of the mouse 11b or the keyboard 11c, to a display area of a state which is selected as an initial state for the simulation to be performed (in this case, a State 1 where the motor 35 is now driving, i.e., "Motor A" in FIG. 4) out of two or more states provided in the state transition matrix shown on the left side of the simulation mode screen shown in FIG. 4 and click the left button of the mouse or press the return key down.
Then, the inputting section 17 detects a position of the cursor existing in the display area of the state selected by the operator and feeds its positional information to the analysis section 18a, and the analysis section 18a converts the positional information supplied by the inputting section 17 to a state code corresponding to the above position (in this case, the State 1) and feeds it to the state transition judging section 18b. The state transition judging 18b, at step SA 2, sets the state (in this case, State 1) corresponding to the state code fed by the analysis section 18a, as the initial state, to the state storing section 18d and, after making it displayed on the display section 11a, goes to step SA3.
Moreover, the operator moves the cursor, using the cursor key of the mouse 11b or the keyboard 11c, to a display area of en event the occurrence of which is desired and which is selected out of two or more states provided in the state transition matrix shown on the left side of the simulation mode screen depicted in FIG. 4 and clicks the left button of the mouse or presses the return key down.
Then, the inputting section 17 detects a position of the cursor existing in the area of the event selected by the operator and feeds its positional information to the analysis section 18a, and the analysis section 18a converts the positional information supplied by the inputting section 17 to an event code corresponding to the above position and feeds it to the state transition judging section 18b. When the operator moves the cursor, by using the cursor key of the mouse 11b or the keyboard 11c, to a display area of the Event 2 wherein the detection signal of the sensor 32 has changed from the OFF to the ON state by the passage of the raw card 36 through the sensor 32 (S1:OFF.fwdarw.ON in FIG. 4), the inputting section 17 detects a position of the cursor existing in the display area of the Event 2 and feeds its positional information to the analysis section 18a and then the analysis section 18a converts the positional information supplied by the inputting section 17 to the event code of the Event 2 corresponding to the position and feeds it to the state transition judging section 18b.
At step SA3, the state transition judging section 18b judges whether the instruction for terminating the simulation has been provided or not, when the cursor is moved by the operator, by using the cursor key of the mouse 11b or the keyboard 11c, to the "END" area where the instruction for the termination of the simulation is provided and which is displayed on the upper part of the simulation mode screen and when the left button of the mouse is clicked or pressed down. If the judgement result turns out to be "YES", the state transition judging section 18b terminates the simulation processing.
On the other hand, if the judgement result turns out to be "NO", i.e., if an instruction for terminating the simulation is not provided by the operator, the state transition judging section 18b goes to step SA4. In the example, because the event code of the Event 2 has been fed to the state transition judging section 18b, the judgement result at step SA3 turns out to be "NO" and the state transition judging section 18b goes to step SA4.
The state transition judging section 18b, at step SA4, judges whether the code supplied by the analysis section 18a is an event code or not. If the judgement result turns out to be "NO", it returns back to step SA3, while, if the judgement result at step SA4 is "YES", i.e., the code supplied by the analysis section 18a is an event code, the state transition judging section 18b goes to step SA5. In this case, because the state transition judging section 18b is provided with the event code of the Event 2, the judgement result at step SA4 turns out to be "YES" and the state transition judging section 18b goes to step SA5.
The state transition judging section 18b, at step SA5, by referring to the state transition matrix read from the state transition storing section 13, based on the event corresponding to the event code supplied by the analysis section 18a and on the state stored in the state storing section 18d and, after deciding a corresponding cell, goes to step SA6. At this point, because the event code of the Event 2 is supplied by the analysis section 18a and the State 1 is stored in the state storing section 18d, the state transition judging section 18b, by referring to the state transition matrix, decides a cell (1, 2). Moreover, if the operator desires the occurrence of an Event 3, i.e., an event that a notice is given by the magnetic head 34a informing of normal completion of writing magnetic data, though a cell (1, 3) is decided at step 10 SA5, because the cell (1, 3) has a description of "/" representing that no action is taken and no transition of a state takes place, the state transition judging section 18b, without carrying out processing from step SA6 to SA8, returns back to step SA4 through step SA3 and is in the standby state to receive a subsequent event.
At step SA6, the state transition judging section 18b, after checking functions of an action processed by the cell decided at step SA5, reading processing time corresponding to the action from the processing time storing section 14 and having the time accumulated in the time accumulating section 18c, goes to step SA7. In the example, the state transition judging section 18b checks functions of the action to stop the driving of the motor 35 and to drive the motor 37 as well as to request the magnetic head 34a to write magnetic data, which is processed by the cell (1, 2) and, after reading processing time (4 ms) corresponding to the action from the processing time storing section 14 and adding the read processing time to the accumulated time (0 ms), has the added processing time accumulated in the time accumulating section 18c. At step SA7, the state transition judging section 18b, after reading out a state subsequent to transition described by a cell decided at step SA5 from the state transition matrix storing section 13 and storing it in the state storing section 18d, goes to step SA8. In the example, because the cell (1, 2) has a description of "=>Under writing" representing that a state subsequent to transition is the State 2 and the State 2 information is stored in the state transition matrix storing section 13, the state transition judging section 18b reads out the State 2 from the state transition matrix storing section 13 and stores it in the state storing section 18d.
At step SA8, the state transition judging section 18b feeds time accumulated in the time accumulating section 18c and the state subsequent to transition stored in the state storing section 18d to the man-machine interface 11 and, after having them displayed on the display section 11a, returns back to step SA 3. In the example, because "4 ms" as the accumulating time is stored in the time accumulating section 18 and the State 2 is stored as a state subsequent to transition in the state storing section 18d, these are displayed in the display section 11a of the man-machine interface 11 as shown in FIG. 4.
The state transition judging section 18b repeats processing at steps SA4 to SA8 until the judgement result at step SA3 turns out to be "NO".
If the "Writing: OK", i.e., the Event 3 is selected as an event the occurrence of which is desired next by an operator, because the state subsequent to transition resulting from the previous simulation is the State 2, the cell (2, 3) is decided and the time of "1 ms "is added and the accumulated time of "5 ms" resulting from the addition is stored in the time accumulating section 18c, and the state subsequent to transition, i.e., the State 3 is stored in the state storing section 18d. In the same manner, if the "Reading: OK", i.e., the Event 5 is selected as an event the occurrence of which is desired next by an operator, because the state subsequent to transition resulting from the previous simulation is the State 3, the cell (3, 5) is decided, however, since the processing time is not described in the cell (3, 5), the previous accumulated time "5 ms" is maintained in the time accumulating section 18c, and the state "S2 Standby" of the place subsequent to transition, i.e., the State 4 is stored in the state storing section 18d. Moreover, if the "S2: OFF.fwdarw.ON", i.e., the Event 7 is selected as an event the occurrence of which is desired next by an operator, because the state subsequent to transition resulting from the previous simulation is the State 4, the cell (4, 7) is decided and the accumulated time "5.5 ms" resulting from the addition of "0.5 ms" is stored in the accumulating section 18c, and the "Motor A" of the state subsequent to transition, i.e., the State 1 is stored in the state storing section 18d.
The accumulated time of "5.5 ms" obtained by the operation of the simulator 18 described above is processing time required by the CPU 24 during the transition of a state from a cell (1, 2) .fwdarw.a cell (2, 3).fwdarw.a cell (3, 5).fwdarw.a cell (4, 7). On the other hand, the time required for the passage of the prepaid card through the sensor 33 after the passage through the sensor 32 is decided depending on physical factors such as the number of revolutions or torque of the motor 37 or the moving distance of the prepaid card, and according to design specifications, it is, for example, "10.+-.1 ms". As a result, this shows that the processing of the CPU is completed during the 10 ms for which the prepaid card passes through the card transfer mechanism 31.
It is also understood from FIG. 3 that, in order to see, in simulation, the execution of processing of re-writing and re-reading due to a failure, one time for each, in writing and reading of magnetic data on and from the prepaid card, the addition of a cell (2, 4) (action of re-writing) and cell (3, 6) (action of re-reading) to the transition of a state of a cell (1, 2) cell (2, 3) cell (3, 5) cell (4, 7) described above. This results in the accumulated time being "9.5 ms".
This result does not comply with the requirement of the lower limit of "9 ms" defined by specifications, causing the operator to review the program for the CPU 24 or the design of the card transfer mechanism 31.
Accordingly, if the execution of the processing to specifications cannot be seen in simulation, the operator, by referring to the display section 11a constituting the man-machine interface 11 and by operating the mouse 11b or the keyboard 11c, changes the processing time described in each cell of the state transition matrix shown in FIG. 3 to the level within a permissible range defined by the specifications and, by seeing again the execution in simulation through the use of the simulator 18, checks if the processing is carried out to the specifications.
In the above description, an example of the simulation to be performed by an operator's selection of an event for every event using the mouse 11b or the keyboard 11c is provided, however, by providing a means to store data on an order of a selected event (hereinafter as an "inputted event log") to the inputting section 17, the subsequent simulation can be performed through use of the inputted event log.
Thus, according to the configurations of the embodiment, since it is possible to perform a simulation based on processing time set for each action described in each cell in the state transition matrix, the simulation is allowed to specifications at the stage of basic design, achieving the reduction in time required for developments and the improvement in the quality.
Second Embodiment
FIG. 6 is a block diagram showing electrical configurations of a program development system shown in a second embodiment of the present invention.
The program development system of the embodiment approximately comprises a man-machine interface 41, an editor 42, a state transition matrix storing section 43, a processing time storing section 44, an overhead time storing section 45, a test script storing section 46, a generator 47, a program storing section 48, an event inputting section 49, a simulator 50 and a simulation result storing section 51. The man-machine interface 41 composed of a display section 41a, a mouse 41b and a keyboard 41c is used to allow an operator to input, by referring to indications of the display section 41a and by actuating the mouse 41b or the keyboard 41c, data required for the creation of a state transition matrix (a state, event, action, state subsequent to transition, processing time and the like), overhead time and events required to perform a simulation based on the state transition matrix of a real time control system designed by the state transition matrix, into the simulator 50 and used to cause results (state subsequent to transition, accumulated time and the like) read from the simulation result storing section 51 to be displayed in the display section 41a. The overhead time represents time required for the completion of the transition from a state or an action to other state or action. For example, when a CPU detects an interrupt request, time is required to store contents of a register within the CPU in a stack, to set an address to be interrupted to a program counter and to fetch a program to be interrupted, i.e., the time is required for implementing actions other than those described in each cell. This time is called "overhead time". This overhead time is required when operations are restored from the interrupt processing as well. Since the simulation in the first embodiment is rough, the overhead time is not taken into consideration, however, in the second embodiment, because a more realistic simulation is performed as if the system were actually operated, this overhead time is taken into consideration in the processing. In this embodiment, the overhead time is set uniformly to 0.5 ms.
The editor 42 is used to create and edit the state transition matrix based on a state, action, state subsequent to transition, processing time and the like inputted using the man-machine interface 41 and to store data on the state transition matrix, processing time and overhead time into the state transition matrix storing section 43, the processing time storing section 44, the overhead time storing section 45 respectively.
Moreover, the editor 42 is adapted to create and edit a test script file used to instruct the simulator 50 to perform a simulation based on events and the like inputted through the use of the man-machine interface 41 and to store the file into the test script storing section 46. The test script file represents a file in timing-chart, text file or message sequence chart form describing the timing of occurrence of each event or the timing of operations of constructive factors of the real time control system required to instruct the simulator 50 to perform a simulation based on t he state transition matrix of a real time control system designed according to the state transition matrix. In this embodiment, a test script file in the text file form is used as the test script file as shown in FIG. 7.
Each of the state transition matrix storing section 43, the processing time storing section 44, the overhead time storing section 45 and the test script storing section 46 is composed of semiconductor memory such as RAM, and a memory medium having large-scale capacity such as FD, HD and the like, and stores data on the state transition matrix, processing time, overhead time and test script file respectively.
The generator 47 is adapted to automatically generate a program (source program) described in a programming language to be incorporated into the real time control system based on data on the state transition matrix read from the state transition matrix storing section 43 and the generated program is stored in the program storing section 48. The program storing section 48 is composed of semiconductor memory such as RAM and the like, and a memory medium having large-scale memory capacity such as FD, HD and the like and is used to store the source program therein.
The event inputting section 49 reads the test script file from the test script storing section 46 and feeds it to the simulator 50.
The simulator 50 approximately comprises an event analysis section 50a, a state transition judging section 50b, a time accumulating section 50c, a state storing section 50d and a time comparison section 50e. The event analysis section 50a is adapted to re-arrange, in order of the time of occurrence, two or more events of the test script file fed by the event inputting section 49 and to create an event inputting sequence described later (refer to FIG. 9) and to feed it to the state transition judging section 50b.
The state transition judging section 50b controls each constructive factor within the simulator 50 and decides a corresponding cell based on an event inputting sequence supplied from the event analysis section 50a and on the state stored in the state storing section 50d and by referring to the state transition matrix read from the state transition storing section 43. The state transition judging section 50b is adapted to read the processing time corresponding to an action processed by the decided cell from the processing time storing section 44 and to have it accumulated in the time accumulating section 50c, and also to read the overhead time required for the transition from the state currently existing in the cell to the state designated as a state subsequent to the transition from the overhead time storing section 45 to have it accumulated in the time accumulating section 50c. The state transition judging section 50b is adapted to read the state subsequent to transition from the state transition matrix storing section 43 and to store it into the state storing section 50d and, after the completion of the simulation, it stores the time accumulated in the time accumulating section 50 and the state subsequent to transition stored in the state storing section 50d as a result of the simulation result into the simulation result storing section 51. Each of the time accumulating section 50c and the state storing section 50d is composed of semiconductor memory such as RAM and the like and stores the accumulated time and the state subsequent to transition respectively.
The time comparison section 50e is adapted to subtract the accumulated time being currently stored in the time accumulating section 50c from the time when an event having an event inputting sequence created by the event analysis section 50c has occurred and, if a result from the calculation turns out to be positive, the calculated result is added, as differential time, to the time accumulated being currently stored in the time accumulating section 50c.
When CPU issues an instruction to request a peripheral device to carry out processing, the time required by the peripheral device for performing the processing in response to the instruction is ordinarily longer than that required by the CPU for giving the instruction to the peripheral device. The difference in time between them is called "differential time" . For example, the time required by the CPU 24 for implementing the action of "Motor A: ON" in a cell (1, 1) of the state transition matrix shown in FIG. 3 is 1 ms, including the overhead time; while the time required by the raw card 36 taken out from the stacker 29 by the card taking-out mechanism 30 for reaching the sensor 32 is 5 ms. Since the required time of "5 ms" is physically decided under the structural constraints of the card taking-out mechanism 30, its change is impossible unless a driving capacity of the motor 35 or a distance for passage of the card is altered. The difference in time between 1 ms for the processing time required by the CPU and 5 ms required by the card taking-out mechanism is differential time.
In the simulation performed in the first embodiment, only the processing time required by the CPU is taken into consideration. However, in the real time control system on which a program to be developed is mounted, because not only the processing time required by the CPU but also operation time required by peripheral devices must be considered, the above embodiment cannot provide a simulation as if the system were more actually operated. Accordingly, in this embodiment, a simulation which takes differential time into consideration is to be performed.
The simulation result storing section 51 consists of semiconductor memory such as RAM and a memory medium having large-scale capacity such as FD, HD and the like and a simulation result containing accumulated time and state subsequent to transition is stored therein.
Operations of the program development system in this embodiment are hereinafter described. A program to be developed by the program development system is a program to be incorporated into the prepaid card selling machine shown in FIG. 2, as in the first embodiment, and accordingly, the specifications of the prepaid card selling machine are the same as in the first embodiment.
An operator, by referring to indications of the display section 41a constituting the man-machine interface 41 and by actuating the mouse 41b or the keyboard 41c, inputs data (state, event, action, state subsequent to transition, processing time and the like) required for creating the state transition matrix based on operations and specifications of the above prepaid card selling machine. This allows the editor 42 to create the state transition matrix and to display it at the display section 41a constituting the man-machine interface 41 and then to store the state transition matrix and processing time at specified memory areas of the state transition matrix storing section 43 and processing time storing section 44. The state transition matrix is the same as that in the first embodiment (FIG. 3) and its description is omitted accordingly.
The operator, by referring to indications of the display section 41a constituting the man-machine interface 41 and by actuating the mouse 41b and the keyboard 41c, inputs events described below, occurring timing and other data (hereinafter as simulation data) in order to instruct the simulator 50 to perform a simulation based on the above state transition matrix according to specifications of the above prepaid card selling machine.
Let it be supposed that, in the standby State 1 to receive an instruction to issue a prepaid card, a detection signal is changed from the OFF to ON state 5 ms after the occurrence of an Event 1 of a request for issuing the prepaid card and, 1 ms after, an Event 2 occurs that the detection signal is changed from the ON to OFF. Furthermore, let it be supposed that the magnetic head 34a informs, 1 ms after receiving a request for writing magnetic data, that the action is normally completed and that the magnetic head 34b, 1 ms after receiving a request for reading magnetic data, that the action is normally completed; that is, the Event 3 and Event 5 have occurred. Again, let it be supposed that, in the standby State 4 to receive a detection signal from the sensor 33, 15 ms after the occurrence of the Event 1, a detection signal of the sensor 33 is changed from the OFF to the ON state and, 1 ms after, the Event 7 occurs that the detection signal is again changed to the OFF state.
The operator, by referring to indications of the display section 41a constituting the man-machine interface 41 and by actuating the mouse 41b and the keyboard 41c, inputs data (hereinafter verification data) on an operational state to show according to specifications in order to compare the data with results from the simulation.
According to specifications, the motor 35 is to be driven until 5 ms elapse after the occurrence of the Event 1 and the motor 37 is to be driven only during a period from 5 ms to 14.about.16 ms after the occurrence of the Event 1.
The simulation data and verification data described above are edited, in the editor 42, to a text file such a test script file as shown in FIG. 7 and are stored in the test script storing section 46. Referring to FIG. 7, the "InitialState:ST1" represents that the initial state at the time of a start of a simulation is the State 1. The "Event:" shows an occurrence of an event not accompanied by a change of a state; for example, the "C_RQ" is a request for an issuance of a prepaid card. The "Object :" represents that parts, equipment or the like written after a mark ":" are an object to be simulated or verified in the paragraph. For example, the "S1" shows a description of a change of a state of the sensor 32. The "Property :" represents that data in the paragraph is simulation data (TEST) or verification data (VERIFY). The "Time:" represents that the time when the change of a state described under the line occurs is absolute time (ABS) or relative time (REL). The "ABS (0)" in the paragraph of the "Event :" C_RQ" shows that an event of a request for an issuance of a prepaid card occurs at absolute time of 0 ms. The "From:" and "To :" represents a source of an event and a place to which the occurrence of the event is transferred respectively. The "StateChange :" represents how the state of the object changes with the passage of time according to a statement described after the mark of ":". For example, "0 (OFF)->5 (ON) ->6 (OFF)" shows that the state is OFF at 0 ms; ON 5 ms after and again OFF at 6 ms. Moreover, the test script file is created by taking the above differential time into consideration.
When an operator, in order to have a simulator 50 perform a simulation based on specifications of the above prepaid card selling machine, by manipulating the mouse 41b or the keyboard 41c constituting the man-machine interface 41, puts this program development system in a simulation mode, a simulation mode window provided with a "START" area to instruct the display section 41a to start a simulation is displayed.
Operations of the simulator 50 and manipulations of an operator to obtain processing time required by the CPU for an issuance of a prepaid card following a purchaser's press-down of a card issuance instruction button (not shown) of the operation and display section 23 are described with reference to a flow chart shown in FIG. 8.
An operator, after moving a cursor to a "START" area to provide instructions for a start of a simulation displayed in a simulation mode window by using a cursor key of the mouse 11b or the keyboard 11c and by clicking the left button of the mouse 11b and pressing down the return key, instructs the simulator 50 to start a simulation. This allows the state transition judging section 50b to go to step SB1 for clearing contents of the time accumulating section 50c to 0 ms and then to step SB2. The state transition judging section 50b reads a head statement of a test script file supplied by the event inputting section 49 at step SB2, sets a corresponding state, as an initial state, to the state storing section 18d and goes to step SB3. In the example, as "InitialState: ST1" is described as a head statement in the test script file shown in FIG. 7, the State 1 is set, as an initial state, to the state storing section 50d.
At step SB3, the state transition judging section 50b judges whether a test script file to be inputted to the event analysis section 50a from the event inputting section 49 exists or not. If the judgement made at step SB3 turns out to be "YES", i.e., there exists a test script file to be inputted to the event analysis section 50a from the event inputting section 49, the state transition judging section 50b, after inputting the test script file to the event analysis section 50a from the event inputting section 49 and goes to step SB4. In this example, as the test script file shown in FIG. 7 is stored in the test script storing section 46, the judgement formed at step SB3 turns out to be "YES" and the state transition judging section 50b inputs the test script file to the event analysis section 50a from the event inputting section 49. At step SB4, the event analysis section 50 creates an event inputting sequence (see FIG. 9) obtained by re-arranging two or more events in the test script file inputted from the event inputting section 49 in order of time of occurrence and, after feeding it to the state transition judging section 50b, goes to step SB5. In this example, the event inputting sequence shown in FIG. 9 is created from the test script file shown in FIG. 7.
At step SB5, the state transition judging section 50b reads the event inputting sequence from the event analysis section 50a in order of an earlier time and judges whether there is an event to be brought about. If the judgement result is "YES", the state transition judging section 50b, after capturing an event being earliest in terms of time out of events to be brought about and the occurrence time, goes to step SB6.
On the other hand, if the judgement result is "NO" at step SB5, the event inputting sequence is scanned in order of an earlier time, and if there is no event to be brought about, a judgment is made that the simulation based on one test script file is complete and operations return back to step SB3 to judge whether there is a test script file to be tested. In this example, the simulation is the first one to be performed based on the test script file shown in FIG. 7 and, as there is an event to be brought about in the event inputting sequence read from the event analysis section 50a, the judgement result at step SB5 is "YES" and the state transition judging section 50b, after capturing an event "C_RQ" being an earliest event out of the event inputting sequence shown in FIG. 9 and its occurrence time (0 ms), goes to step SB6.
At step SB6, the state transition judging section 50b, by referring to the state transition matrix read from the state transition matrix storing section 13, judges whether the captured event is an object to be simulated. If the result is judged to be "NO", the state transition judging section 50b returns back to step SB5. On the other hand, if the judgement result is "YES" at step SB6, i.e., the captured event is any of events described in the state transition matrix and is an object to be simulated, the state transition judging section 50b goes to step SB7. In this example, the event "C_RQ" is described as the Event 1 and, as it is an object to be simulated, the result at step SB6 is judged to be YES.
At step SB7, the time comparison section 50e subtracts the accumulated time being currently stored in the time accumulating section 50c from the time of occurrence of an event that the state transition judging section 50b has captured and judges whether the subtracted result is positive, i.e., there is differential time. If the result is judged to be "NO", the time comparison section 50e goes to step SB9. If the result is judged to be "YES"; i.e., there is differential time, the time comparison section 50e goes to step SB8. In the example, the Event 1 is an event of a request for issuance of a prepaid card and is not related to an instruction by which the CPU 24 instructs a peripheral device to perform processing and, accordingly, there is no differential time, and the judgement result at step SB7 is "NO", and the time comparison section 50e goes to SB9.
At step SB8, the time comparison section 50e adds the differential time to the accumulated time being now stored in the time accumulating section 50c and, after storing the result of the addition in the time accumulating section 50c, goes to step SB9.
At step SB9, the state transition judging section 50b, after deciding a cell, based on an event captured from the event analysis section 50a and a state stored in the state storing section 18d and by referring to the state transition matrix read from the state transition matrix storing section 13, goes to step SB10. In this example, the state transition judging section 50b, as the Event 1 has been captured from the event analysis section 50a and the State 1 has been stored in the state storing section 50d, decides a cell (1, 1) by referring to the state transition matrix.
At step SB10, the state transition judging section 50b, adds the overhead time. read from the overhead time storing section 45 to accumulated time being accumulated in the time accumulating section 50c, stores the result of the addition in the time accumulating section 50c and goes to step SB11. In the example, the state transition judging section 50b adds the overhead time (0.5 ms) read from the overhead time storing section 45 to the accumulated time (0 ms) being now stored in the time accumulating section 50c and store the result of the addition (0.5 ms) in the time accumulating section 50c.
At step SB11, the state transition judging section 50b, after checking a function of an action to be processed by a cell decided at step SB9 and reading processing time corresponding to the action from the processing time storing section 44 and adding it to accumulated time stored in the time accumulating section 50c and then storing the result of the addition to the time accumulating section 50c, goes to step SB12. In the example, the state transition judging section 50b checks the function of the action to actuate the motor 35, which is processed by a cell (1, 1), and reads processing time (0.5 ms) corresponding to the action from the processing time storing section 44 to add it to the time (0.5 ms) accumulated up to date which is being stored in the time accumulating section 50c, and then store the result (1 ms) of the addition in the time accumulating section 50c.
At step SB12, the state transition judging section 50b reads the state subsequent to transition described in the cell decided at step SB9 from the state transition storing section 43, stores it to the state storing section 50d. In this example, since the state subsequent to transition is not described in a cell (1, 1), the state subsequent to transition is not changed and the State 1 remains stored in the state storing section 18d.
At step SB13, the state transition judging section 50b stores the time accumulated in the time accumulating section and the state subsequent to transition stored in the state storing section 50d, as a simulation result, into the simulation result storing section 51 and then returns back to step SB5. In the example, the accumulated time (1 ms) and the state subsequent to transition (State 1) are stored as a simulation result into the simulation result storing section 51.
On the other hand, if the judgement result at step SB3 is "NO", i.e., the test script file is not continuously inputted into the event analysis section 50a from the event inputting section 49, the state transition judging section 50b judges that the simulation based on all test script files stored in the test script storing section 46 is completed and goes to step SB14.
At step SB41, the state transition judging 50b reads the simulation result stored in the simulation result storing section 51, feeds it to the man-machine interface 41 and then terminates the simulation processing. By this, on the display section 41a of the man-machine interface 41, a simulation result obtained up to now is displayed.
Referring to FIG. 9, occurrences of an event to be brought at an early time following the event "C_RQ" in the event inputting sequence and events occurring thereafter and simulations corresponding to these are described below. Moreover, in the description below, though a detailed explanation of processing at each step in the flow chart shown in FIG. 8 is omitted, after the processing at steps SB3 to SB13 are repeated, it is needless not to say that, in the end, the processing at step SB14 is to be performed.
First, the state transition judging section 50, captures the event "S1: OFF.fwdarw.ON" and the occurrence time (5 ms) by referring to the event inputting sequence in FIG. 9. Since the event "S1:OFF.fwdarw.ON" is described as the Event 2 in the state transition matrix shown in FIG. 3 and is an object to be simulated, the time comparison section 50e subtracts the accumulated time (1 ms) being currently stored in the time accumulating section 50c from the occurrence time (5 ms) of the Event 2. Because the result of the subtraction is positive (4 ms), the time comparison section 50e, after adding the differential time (4 ms) to the accumulated time (1 ms) being now stored at the time accumulating section 50c, stores its result of the addition (5 ms) into the time accumulating section 50c.
The state transition judging 50b, after deciding a cell (1, 2) based on the Event 2 captured from the event analysis section 50a and the State 1 being stored in the state storing section 18d and by referring to the state transition matrix, reads the overhead time (0.5 ms) out of the overhead time storing section 45 and adds it to the accumulated time (5 ms) being stored in the time accumulating section 50c and then stores the result of the addition (5.5 ms) into the time accumulating section 50c. The state transition judging section 50b, after checking a function of an action of stopping the driving of the motor 35 and starting the driving of the motor 37 to be processed in a cell (1, 2) and of requesting for writing magnetic data into the magnetic head 34a, reads the accumulated time (4 ms) from the processing time storing section 44 and adds it to the accumulated time (5.5 ms) being now stored in the time accumulating section 50c and then stores the result of the addition (9.5 ms) into the time accumulating section 50c.
The state transition judging section 50b, after reading the state subsequent to transition (State 2) described in a cell (1, 2) from the state transition matrix storing section 43 and storing it into the state storing section 50d, stores the time (9.5 ms) accumulated in the time accumulating section 50c and the state subsequent to transition (State 2) stored in the state storing section 50d as simulation results into the simulation result storing section 51.
The state transition judging section 50b captures the state "S1:ON.fwdarw.OFF" and its occurrence time (6 ms) by referring to the event inputting sequence shown in FIG. 9, however, the event "S1:ON.fwdarw.OFF" is not described in the state transition matrix in FIG. 3 and is not an object to be simulated, again by referring to the event inputting sequence, captures the event "Writing OK" and the occurrence time (*). Though the event "Writing OK" is described as the Event 3 in the state transition matrix shown in FIG. 3 and is an object to be simulated, the occurrence time (*) shows that the processing of the event "Writing OK" is executed subsequent to the previous processing, no differential time is produced.
Then, the state transition judging section 50b, after deciding a cell (2, 3) based on the Event 3 captured from the event analysis section 50a and the state (State 2) stored in the state storing section 18d and by referring to the state transition matrix shown in FIG. 3, reads overhead time (0.5 ms) from the overhead time storing section 45 and adds it to the accumulated time (9.5 ms) being stored in the time accumulating section 50c and then stores the result of the addition (10 ms) to the time accumulating section 50c. The state transition judging 50b checks a function of an action, which is processed by a cell (2, 3), of requesting the magnetic head 34b to read magnetic data of a prepaid card, reads processing time (1 ms) from the processing time storing section 44, adds it to the time accumulating section 50c and stores the result of its addition (11 ms) into the time accumulating section 50c.
The state transition judging 50b, after reading the state subsequent to transition (State 3) described in a cell (2, 3) from the state transition matrix storing section 43 and storing it into the state storing section 50d, stores the time (11 ms) accumulated in the time accumulating section 50c and the state subsequent to transition (State 3) as simulation results into the simulation result storing section 51.
The state transition judging section 50b, by referring to the event inputting sequence, captures the event "Reading OK" and the occurrence of time (*).
Though the event "Reading OK" is described as the Event 5 in the state transition matrix as shown in FIG. 3 and is an object to be simulated, the occurrence time (*) shows that the processing of the event "Reading OK" is executed subsequent to the previous processing, no differential time is produced.
Then, the state transition judging section 50b, after deciding a cell (3, 5) based on the Event 5 captured from the event analysis section 50a and the state (State 3) stored in the state storing section 18d and by referring to the state transition matrix shown in FIG. 3, reads the overhead time (0.5 ms) from the overhead time storing section 45 and adds it to the accumulated time (11 ms) being stored in the time accumulating section 50c and then stores the result of the addition (11.5 ms) to the time accumulating section 50c. The state transition judging 50b, though not making a check on a function of an action due to non-existence of any action to be processed in a cell (3, 5), reads processing time (0 ms) from the processing time storing section 44, adds it to the accumulated time (11.5 ms) now being stored in the time accumulating section 50c, stores the result of its addition (11.5 ms) in the time accumulating section 50c.
The state transition judging section 50b, after reading the state subsequent to transition (State 4) described in a cell (3, 5) from the state transition storing section 43 and storing it into the state storing section 50d, stores the accumulated time (11.5 ms) stored in the time accumulating section 50c and the state subsequent to transition (State 4) stored in the state storing section 50d, as simulation results, in the simulation result storing section 51.
The state transition judging section 50b, by referring to the event inputting sequence shown in FIG. 9, captures the event "S2:OFF.fwdarw.ON" and the occurrence time (15 ms). The event "S2: OFF.fwdarw.ON" is described as the Event 7 in the state transition matrix in FIG. 3 and is an object to be simulated, the time comparison section 50e subtracts the accumulated time (11.5 ms) being currently stored in the time accumulating section 50c from the occurrence time (15 ms) of the Event 7. Because the result of the subtraction is positive (3.5 ms), the time comparison section 50e, after adding the differential time (3.5 ms) to the accumulated time (15 ms) being now stored at the time accumulating section 50c, stores its result of the addition (15 ms) into the time accumulating section 50c.
Then, the state transition judging section 50b, after deciding a cell (4, 7) based on the Event 7 captured from the event analysis section 50a and the state (State 4) stored in the state storing section 18d and by referring to the state transition matrix shown in FIG. 3, reads the overhead time (0.5 ms) from the overhead time storing section 45 and adds it to the accumulated time (15 ms) being stored in the time accumulating section 50c and then stores the result of the addition (15.5 ms) to the time accumulating section 50c.
The state transition judging 50b checks a function of an action, which is processed by a cell (4, 7), for stopping of the motor 37, reads processing time (0.5 ms) from the processing time storing section 44, adds it to the time (15.5 ms) accumulated in the time accumulating section 50c and stores the result of its addition (16 ms) into the time accumulating section 50c.
Then, the state transition judging section 50b, after reading the state subsequent to transition (State 1) described in a cell (4, 7) and storing it into the state storing section 50d, stores the time (16 ms) accumulated in the time accumulating section 50 and the state subsequent to transition (State 1) stored in the state storing section 50d as simulation results, into the simulation result storing section 51.
Though the state transition judging section 50b, by referring to the event inputting sequence shown in FIG. 9, captures the event S2: ON.fwdarw.OFF" and its occurrence time (16 ms), the "S2:ON.fwdarw.OFF" is not described in the state transition matrix in FIG. 3 and is not an object to be simulated, it refers again to the event inputting sequence shown in FIG. 9. However, since all the event inputting sequences shown in FIG. 9 have occurred, the state transition judging 50b judges that a simulation based on one test script file is complete.
The simulation described above is an example wherein writing and reading on and from the magnetic data of a prepaid card have succeeded in one operation and the transition of a state is as follows: A cell (1, 1), .fwdarw.cell (1, 2).fwdarw.cell (2, 3).fwdarw.cell (3, 5).fwdarw.cell (4, 7). This is hereinafter referred to as "Simulation Result 1".
If a simulation is performed that a failure occurs once for every writing and reading on and from the magnetic data of a prepaid card, the transition of a state is as follows: A cell (1, 1).fwdarw.cell (1, 2).fwdarw.cell (2, 4).fwdarw.cell (2, 3).fwdarw.cell (3, 6).fwdarw.cell (3, 5) cell.fwdarw.(4, 7). No description of the test script file, event inputting sequence and operations of the simulator 50 based on these is not provided here, however, the accumulated time (16.5 ms) is obtained in the same manner as those described above. This is hereinafter referred to as "Simulation Result 2".
Two test script files of the two simulations are stored, in advance, in the test script storing section 46. When a simulation based on these two files is complete, the state transition judging section 50b reads the simulation result stored in the simulation result storing section 51 and, after it is fed to the man-machine interface 41, the simulation is terminated. As shown in FIG. 10, this allows simulation results to be displayed, as a timing-chart, in the display section 41a of the man-machine interface 41.
FIGS. 10(a) to (e) show waveforms of simulation data on the timing of occurrences of the Event 1, Event 2, Event 3, Event 4, Event 5 and Event 7 in the state transition matrix shown in FIG. 3 and FIGS. 10(f) to (g) show waveforms of verification data on the timing of occurrence of a signal to drive the motor 35 (Motor A) and the motor 37 (Motor B). These are created from the test script file shown in FIG. 7. FIGS. 10(h) and (i) show the Simulation Result landSimulation Result 2 respectively, and FIG. 10(j) is a wave form showing the timing of occurrence of a signal to drive the motor 37 (Motor B). The comparison between FIG. 10(g) and FIG. 10(j) shows that, the range of allowance for timing of the ON/OFF switching of a signal to drive the motor 37 (Motors B) is between 15.+-.1 ms in the case in FIG. 10(g), while a driving signal remains ON even after an elapse of 16 ms in the case of in FIG. 10(j), i.e., the specifications are not met in Simulation Result 2 accordingly.
Thus, an operator is allowed to repeat simulations until the specifications are met, based on the Simulation Result 2 and by referring to the state transition matrix (FIG. 3) being displayed in the display section 41a constituting the man-machine interface 41 and by manipulating the mouse 41b or the keyboard 41c, in order to reduce processing time of CPU 24 by changing actions, processing time and the like described in each cell constituting the state transition state so that they are within the range of allowance or by replacing with a CPU having more high-speed operations or to improve responsivity in the magnetic heads 34a or 34b.
Moreover, in the example described above, the step SB6 is provided and, if an event not designated in the state transition matrix is inputted, the simulator returns back to the step SB5, however, in that case, the flow chart can be so configured that the step SB6 is not provided and the simulator passes through the steps SB7 to SB13 without performing any processing.
Thus, according to the configurations of the second embodiment, because a simulation of a system can be performed based on the state transition matrix by suitably setting processing time for every action described in each cell in the state transition matrix and by taking the overhead time and differential time into consideration, a more realistic simulation, as if the system were actually operated, can be performed at the stage of basic design compared with that in the above first embodiment, thereby achieving the reduction in time required for developments and the improvement in the quality.
Third Embodiment
According to this third embodiment, an electrical configuration of a program development system is approximately the same as that of the program development system of the second embodiment shown in FIG. 6. However, functions of each constitutional factors are different as described later. A program to be developed by this program development system, as in the first embodiment, is a program to be incorporated into the prepaid card selling machine shown in FIG. 2 and specifications of the prepaid card selling machine is the same as that of the first embodiment.
In the operations of the first and second embodiments, only processing time required by the CPU 24 is taken into consideration, however, unless processing time required by peripheral devices such as magnetic heads 34a and 34b is taken into consideration, the simulation is not realistic and cannot reproduce a more really mounted state.
In this embodiment, a state transition matrix of operations of magnetic heads 34a and 34b as shown in FIG. 11 is created and a simulation is performed in relation to the simulation based on the state transition matrix shown in FIG. 3. As a method for creating the state transition matrix shown in FIG. 11 is the same as that for the state transition matrix shown in FIG. 3, the description thereof is omitted.
The "Standby state for request" shown on the most upper line in FIG. 11 represents the magnetic heads 34a and 34b are in a standby state (hereinafter as State 1) to receive a request from the CPU 24 for writing and reading magnetic data; the "Under Writing" representing that the magnetic head 34a is in a state (hereinafter as State 2) to write magnetic data to a raw card 36 and the "Under Reading" representing that the magnetic head 34b is in a state (hereinafter as State 3) to read magnetic data from the prepaid card.
The "Writing" shown on the most left line in FIG. 11 represents a state where there is a request from the CPU24 for writing specified magnetic data to the raw card 36 (hereinafter as Event 1); the "Reading" representing a state where there is a request from the CPU for reading magnetic data from a prepaid card (hereinafter as Event 2); the "Writing Completion" representing a state where a message is received informing that the magnetic head 34a has completed writing of magnetic data to the raw card 36 (hereinafter as Event 3); and the "Reading Completion" representing a state where a message is received informing that the magnetic head 34b has completed reading of magnetic data from the prepaid card (hereinafter as Event 4).
In the state transition matrix shown in FIG. 11, when a cell which is a point of intersection of an event and a state, for example, a point of intersection of the State 1 and the Event 1 is represented as a cell (1, 2), the contents of descriptions of each cell have the following meanings, i.e., the "Writing Start" in a cell (1, 1) represents a standby state (State 1) of a request from the CPU 24 for writing magnetic data showing an action of the magnetic head 34a to start writing magnetic data to the raw card 36, in response to the occurrence of the Event 1 of a request from the CPU 24 for writing magnetic data. Moreover, the "=>Under Writing" in a cell (1, 1) represents that the state subsequent to transition is the State 2 and the numeric number (1) shows that processing time required for the above action is 1 ms.
The "Writing Completion Set" in a cell (1, 1) represents that, when the magnetic head 34a completes writing of magnetic data to the raw card 36, a message is sent informing that the writing is complete.
The "Reading Start" in a cell (1, 2) represents a standby state (State 1) of a request from the CPU 24 for reading magnetic data showing an action of the magnetic head 34b to start reading magnetic data to the raw card 36, in response to the occurrence of the Event 1 of a request from the CPU 24 for reading magnetic data. The "=>Under Reading" in a cell (1, 2) represents that the state subsequent to transition is the State 3 and the numeric number (1) shows that processing time required for the above action is 1 ms. The "Reading Completion Set" in a cell (1, 2) represents that, when the magnetic head 34b completes reading of magnetic data from the raw card 36, a message is sent informing that the reading is complete.
The mark (X) represents that there is no combined state of the event and the state in cells (1, 3) and (1, 4).
The "Error Return" in a cell (2, 1) represents a state (State 2) where the magnetic head 34a is writing magnetic data to the raw card 36 and a request (Event 1) for writing magnetic data occurs from the CPU 24, showing an action to inform the CPU that only one raw card 36 can be written in one operation according to the specification. The mark "=>-" in a cell (2, 1) represents that operations remain in a present state, i.e., in the State 2, and the numeric number (0.5) shows that processing time required for the above action is 0.5 ms.
The "Error Return" in a cell (2, 2) represents an action to judge that an abnormality has occurred if an request for reading magnetic data is supplied from the CPU 24 regardless of the state (State 2) where the magnetic head 34a is writing magnetic data to the raw card 36 and to inform the CPU of it. The mark "=>-" in a cell (2, 2) represents that operations remain in a present state, i.e., in the State 2, and the numeric number (0.5) shows that processing time required for the above action is 0.5 ms.
The "Data Flag Set: Writing Completion" in a cell (2, 3) represents a state (State 2) where the magnetic head 34a is writing magnetic data to the raw card 36 and shows an action to set a data flag that the writing is complete, in response to the Event that a message is received informing that the magnetic head 34a has completed writing of magnetic data to the raw card 36. Moreover, the "Standby State for Request" in a cell (2, 3) represents that the state subsequent to transition is the State 1 and the numeric number (1) shows that processing time required for the above action is 1 ms.
In a cell (2, 4), the mark "/" represents that no action is implemented and no transition of a state takes place therein. The meaning of the mark "/" is the same as in a cell (3, 3) and accordingly the description thereof is omitted.
The "Error Return" in a cell (3, 1) represents an action to judge that an abnormality has occurred if an request (Event 1) for writing magnetic data is supplied from the CPU 24 regardless of the state (State 3) where the magnetic head 34a is reading magnetic data from the prepaid card and to inform the CPU of it. The mark "=>-" in a cell (3, 1) represents that operations remain in a present state, i.e., in the State 3, and. the numeric number (0.5) shows that processing time required for the above action is 0.5 ms.
The "Error Return" in a cell (3, 2) represents a state (State 3) where the magnetic head 34b is reading magnetic data from the prepaid card and a request (Event 2) for reading magnetic data is given by the CPU 24, showing an action to inform the CPU that only one prepaid card can be written in one operation according to the specification. The mark "=>-" in a cell (2, 2) represents that operations remain in a present state, i.e., in the State 3, and the numeric number (0.5) shows that processing time required for the above action is 0.5 ms.
The "Data Flag Set: Reading Completion" in a cell (3, 4) represents a state (State 3) where the magnetic head 34b is reading magnetic data from the prepaid card and shows an action to set a data flag that the reading is complete, in response to the event (Even |