JPH0511997A - System configuration method - Google Patents

Abstract

PURPOSE:To simplify and unify a program configuration for deciding state transition and also for state transition by taking a unified configuration for an object of a process which becomes a sequencial machine after being made to be abstract. CONSTITUTION:A software is divided into plural functional parts, and each functional part is constituted by a sequencial machine consisting of state transition programs, and respective sequencial machines are connected by way of a message to which a destination information and a cause information about state transition are added, and each sequencial machine is permitted to be accessed by its own sequencial machine and a message. If this method is applied, for example, to a functional test of a telephone switchboard and a test material of simulated reflux test and others, a test procedure 1 stored in the file of highest order is, by way of a test controlling part 2, provided to simulators 3-5. In that case, a test scenario described in a scenario macro and a test program described in a state transition macro are translated by a compiler into the form which a machine can execute, and above mentioned test is carried out.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The field of use of the present invention relates to a sequential machine and, more particularly, to a system for constructing a computer program (software).

[0002]

2. Description of the Related Art Conventionally, as a first field in which computer programs are used, there is a so-called built-in system such as a vending machine in which the existence of the program cannot be seen from the outside. The second field is, for example, a communication system, an image device, or the like that uses a program to transmit, exchange, store, or control information. In this case, there are cases where the computer is a micro computer, and cases where the whole is included in an LSI including these. The third field is that everything is executed on the computer, such as the test of the above system and the execution of simulation.

A feature common to these is that the objects to be programmed have a sequence property, and the sequence is executed / processed by a program.

The earliest development and publication of this type of technology has been in the field of computer-controlled electronic exchanges. The "Introduction to the Electronic Exchange Program" published in 1976 best summarizes the results. FIG. 4.15 in {4.1.4 State transition diagram description of switching function} of this document shows that the exchange has a sequence property and its operation is abstracted by the state transition diagram. There is. In addition, {4.5. In task execution}, the state transition from the state without connection in the switch network for exchange to the state with connection to a certain terminal is defined as a task, and this task is made into a macro from the viewpoint of exchange operation. Is shown to be executed interpretively. Although it is complicated to determine such a task, {4.
4.4 State Analysis}, FIG. 4.68 and the like show that the task is determined by the state number STN corresponding to the state and the information of the result activated and processed by the information from the outside.

The sequential machine which is the object of the present invention is an abstract machine which has a state and makes a state transition with respect to a transition cause from the outside. Based on its automaton theory, the CCITT
Recommendation Z. 100 CCITT-SDL (Specificat
ionand Description Language) has been decided. This recommendation only shows that there is a state as an abstraction and there is a state transition for the cause of the transition, and it has no specificity beyond the automaton theory.

[0006]

The problem with these methods is that even if they seem simple as in the Autotonon theory and SDL, they are complicated in structure as in the above-mentioned documents when they are actually applied. That is not to get. For this reason, different control configurations are taken for each model, and the program (or software) does not become a unified program / software.

The next problem is that it takes more time for the computer to determine the state transition and the capacity of the system is lowered. The request to save this time is considered to be the cause of the individual control configuration in each system.

Still another problem is that the state transition program is complicated. In the above exchange, tens of thousands of "calls" are controlled simultaneously under one program. Ser
For a "call" that requires a screw, a task control block (TCB) (or its equivalent) is assigned to one, as is usually done by an operating system (OS), and temporary information is stored here, and an exchange program Is usually made by mixing the OS and application programs. Therefore, it is known that the programming is troublesome and the exchange program is low in productivity.

A first object of the present invention is to adopt a uniform structure for processing objects that are abstracted into a sequential machine, and to unify the structure of programs for determining state transitions and state transitions. An object of the present invention is to provide a system configuration method that can be simplified.

A second object is to provide a system configuration system capable of providing a mechanism and a program for determining state transition at high speed.

A third object of the present invention is to provide a system configuration method capable of extremely easily creating a state transition program.

[0012]

In order to achieve the above object, a system configuration method according to the present invention is a system configuration method for configuring a system including software, in which the software is divided into a plurality of functional parts, The functional part is composed of a sequential machine consisting of a state transition program, and the sequential machines are connected by a message with destination information and state transition cause information, and each sequential machine is allowed to access only its own sequential machine and the above messages. It is something that is done.

The state transition program forming each of the above sequential machines is described by a macro instruction.

All messages can have a unified structure.

Preferably, a sequential machine having a timing function is provided. This sequence machine receives a message including a time interval and a count value as supplementary information, performs counting at each time interval, and after finishing counting the count value, sends a message to the effect that the sender is the destination to notify the time end. Send it back.

[0016]

In the present invention, the object of programming is not a single abstract machine but a plurality of sequential machines. This principle is a method that has been conventionally known in the automaton theory and logic circuits. In software, a method of connecting a plurality of abstract sequential machines with each other by a message has been known, and has been incorporated into SDL. In the present invention, this method is adopted, and the whole is configured (hierarchically) as a collection of sequential machines according to a large number of single functions / concepts. This means that the creation of individual state transition programs becomes extremely easy.

In this case, there are two problems. The first is
It is how to divide the abstract machine. This is a design technique issue and will not be discussed here. Secondly, since the number of state transition decisions is extremely large, there is a problem of how to speed up the processing.

According to the present invention, the first speed-up is achieved by including the destination information in the message, easily determining the partner's sequential machine from this destination information, and extracting the status information. Next, the transition cause information is included in the message. This way, you can easily get both the state information and the cause of the transition.
Achieve the second speedup.

Further, the message has sender information. As a result, both the sending and receiving can be identified by looking at the message, which makes debugging extremely easy. Also, the abstract machine that controls the timing function described below can obtain the destination information based on the source information of the message to itself.

The transition cause information can usually have various kinds of supplementary information. In the present invention, an abstract machine that controls timing functions by providing it with timing information and the like is provided. Thus, all state transitions can be allowed without any interruption. This requires notation of timing / interruption, but it is more important to contribute to simplification of the state transition program, simplification of the control structure, and speeding up.

In this way, the sequential machines can be easily designed / described one by one, but in the actual design, the interaction between the TCB and the state transition program is still troublesome. Therefore, in order to make it easier, the state transition program is allowed to access only the limited special area of the message and TCB. As a result, the target to be processed looks like a virtual processor that processes limited registers. Therefore, it is a messe to look like a processor.
And TCB are limited to special areas, and macro instructions for processing these are provided. The macroinstruction is a macroinstruction because it includes accesses such as TCB, but the user can use the registers 1, 2 ,. ． ． ．
Add, subtract, multiply, and divide, and make a decision / branch. This virtual processor is an indicator (condition code) based on the execution result of a macro instruction like a normal processor for judgment / branching.
Stand up. The decision / branch instruction refers to this. As a result, the state transition program can be constructed by simple processing, and the program becomes easier to make.

Further, as a macro instruction, an ordinary subroutine is used.
By providing the Chin branch instruction and the return function, the problem when only the above macro instruction can be used is solved. For example, many and various types of data access are indispensable in an exchange, but these can be prepared by preparing routine routines. Such a routine may be thought of as a data access macro.

In order to make a state transition program easier, a subroutine containing states is prepared. In the usual concept, there is a concept of subroutine in a program for state transition. In the present invention, this is expanded to handle a program for (plural) states and state transitions as one subroutine. The subroutine is provided with a plurality of outlets.
Since this subroutine corresponds to a block composed of a plurality of states and a plurality of state transition programs, it can be equivalently provided with a large function by a simple description. Therefore, it becomes possible to improve the effective software productivity.

In the end, the virtual processor is a condition code for judgment / branching, a state number, a macro step counter, (these are extensions of conventional program control words), and a stack register for subroutines. It can be regarded as having one register consisting of the conventional TCB and the conventional TCB.

In some cases, one program may be shared by several abstract machines (specifically, TCBs), and therefore an indicator indicating either common or individual is provided in the TCB.

As a method of addressing a macro instruction, various methods such as a literal that directly uses a value in the long register, a direct method that directly uses the TCB value, and an indirect method that indirectly uses the value of the TCB can be used. As a result, the individuality of the program is reduced, so that the reusability of the program is enhanced or the ease of understanding and design is further enhanced, which contributes to the improvement of software productivity.

Specifically, the simplest method for determining the partner's sequential machine from the destination information is to obtain the partner by adding / subtracting to / from a certain base using the code of the destination information section as a value. Is. The following method is to access the table and obtain the other party by adding / subtracting the code of the destination information section to a certain base. The most complicated method is that the destination information is composed of several blocks, and the primary block is accessed in the first block and the secondary table is accessed in the subsequent block. Applicable to large hierarchical systems. Regarding the source identification, the source can be similarly obtained from the source information. This table access can be performed at extremely high speed, and the table search, the two-dimensional table access, etc., can be performed by using both the destination state thus obtained and the transition cause information included in the message. Thus, the start address of the task / state transition program to be executed can be easily obtained.

The virtual processor can be implemented together with a macro instruction, a condition code, a status-containing subroutine, or the like, or separately.

Further, by standardizing the messages sent and received between the sequential machines, all the mechanisms become common. Therefore, all (many) distributed sequential machines can be realized by a single physical processor or can be realized by dividing them into several physical processors. In other words, the standardization makes it possible to separate the correspondence between the process (sequential machine) and the physical processor. This is
It means that a unified architecture is possible, and the degree of diversion of programs will increase.

[0030]

EXAMPLE This example is applied to a telephone exchange testing machine. The functions are "function test" and "simulated environment test". The former is, for example, to pick up a handset of a telephone and confirm whether "a dial sound" appears, "does it react correctly when a stimulus is given?" The latter is for extracting abnormalities that rarely occur in the system while continuously giving normal telephone calls and repeating the normal operation a large number of times over a long period of time. Conventionally, these were done manually. In particular, the latter is extremely technically difficult because it is inevitable to make a reverse exchange.

FIG. 1 shows the functional configuration of this embodiment. An exchange 6 as a device under test is located at the lowermost part, and a telephone simulator 3, a relay stand simulator 4, and a relay line simulator 5 are connected to this to replace the manual operation. The test procedure 1 contained in the uppermost file is given to each simulator via the test control unit 2. Test 7 is
It shows a state where a test is being performed by the telephone simulator 3.

FIG. 2 shows the same figure focusing on the hardware, and the elements corresponding to the elements shown in FIG. 1 are assigned the same numbers. Each of the simulators 3, 4 and 5 is multiplexed and controlled by an individual processor for each type. The test is performed in units of groups (test groups) that are composed of several types of simulators, and the test control unit 2 controls the test state for each unit. That is, test control C
PU2, like others, performs multiple test control functions. The highest-level E-7100 is a minicomputer 1, which controls a test preparation (compilation, etc.) and a man-machine interface for test execution control.

FIG. 3 shows the test flow. A test specification (program checklist) is created from the functional specifications, and then converted into a sequence of terminal-compatible operations called a test scenario. This is written in a macro language such as a scenario macro. According to the test scenario, a signal is given to the exchange (X) as shown in the figure, and the signal from the exchange is confirmed to proceed. The test scenario described by these scenario macros and the one described by the state transition macro described later are called a test program, and are converted into a form (object code) to be executed by a machine by a compiler provided in the E-7100. The test is performed as described in 1.

In the above-mentioned normal function test, the program may flow in a straight line, but in order to perform the simulated environment test, the exchange is busy because the subscriber or the like operates abnormally or many calls are made. We have to deal with normal operation including quasi-normal operation such as. The switch is a complex sequential machine, but the simulated environment test must also be a complex sequential machine. A sequential machine is an abstract machine that has states and transitions between states. The exchange is a huge program because it is a complicated sequential machine. Simulated environment testing is also a huge program with complex sequential machines. But,
If you are developing a huge program for the test, you will not know whether you are testing or not.

Therefore, this embodiment realizes this extremely easily. FIG. 4 shows the concept. The scenario macro corresponds to a part of the program that makes the state transition. It is shown as SM in the figure. You can easily create a large program by connecting large parts like this. FIG. 5 shows the device. The scenario macro SM is, as shown in FIG.
It has a plurality of outlets 51-54. The input and output of each scenario macro SM are connected to each other as shown in FIG. FIG. 5C shows the contents of the scenario macro SM as well. Usually, a compiler converts a macro into a state transition program. However, since this complicates the compiler, it is realized by "subroutine including state" here. Details will be described later.

Next, a more detailed description of the tester itself will be described.
FIG. 6 shows a software-like functional configuration. A management subsystem 62, a test subsystem 63, and a support subsystem 64 are located under the simulator system 61 at the top. The test control unit 6 is provided under the test subsystem 63.
5, the supervisor 66 and the test program 67 are located, and the preprocessing unit 69 and the SDL compiler 68 are located under the support subsystem 64. Furthermore, at the bottom of the figure, the input section 7 is added under the test program 67.
0, the signal detection unit 71, the signal sequence 72, the signal output unit 73 and the output unit 74 are located. In the figure, a block with a black circle “•” on the right shoulder indicates that it is realized by a single function state transition program in this embodiment. The test scenario given to the preprocessing unit 69 at the right end is stored in the test program 67 of each simulator. This will change with each test. As shown at the bottom of the figure, the signal sequence 72 operates by receiving an input via the signal detection unit 71, and notifies the upper test program 67 as necessary. The high-order test program 67 gives a command to the low-order signal sequence 72 as necessary while performing the state transition. The signal sequence 72 provides outputs to the hardware as needed while making state transitions. As such, this system is thoroughly layered. FIG. 7 shows the situation.

FIG. 8 is a data flow diagram showing the functions of the input / output hardware, and FIG. 9 is a data flow diagram showing the functions of the software. In the illustrated range, the scanner 91 is hardware, and the periodic scanning unit 92 is activated every 4 ms, for example, to detect a change in the line state. The push button (PB) code detector 93 is also activated at a fixed time. Programs 100 to 103 connected to the right end signal distributor 104
Drives the hardware (often) immediately when given an input command. These are used as subroutines in the state transition program. Except for these, the functions shown here are all sequential machines and are realized by state transition programs. This program transitions from state to state without pausing.

The feature of this system is that it is composed of a large number of aggregates of the state transition programs of the single function thus layered. An example of a single function state transition program is shown in FIG. In the case of the figure, it can be seen that only test control is performed. The test control unit uses a mode in which this one state transition program is shared by many test groups. This is achieved by assigning a task control block for each test group and making all state transition programs reentrant.

An example of a test portion different from the above will be shown. FIG. 11 is a time chart for confirming that the signal S is created and the signal R is normally returned. If the return of the signal R is less than the time Ts, it is too early, if it is more than Tl, it is too late, and only the middle is allowed. FIG. 12 shows a part of the state transition program for this purpose, but ordinary knowledge in the industry will not require further explanation. Since such a part is different for each test object, a state transition program is made to correspond to each circuit and each has a task control block. As a special measure, the time values Ts and Tl are not directly specified, but the time information is recorded in a certain area of the task control block and indirectly specified in the state transition program.
This is indicated by (T ..) in the figure. By doing so, even if the time is different for each test target, it can be easily dealt with by changing the data of the task control block by the transfer command, and the commonality of this part of the state transition program is enhanced.

This system is a complex of abstract machines represented by many state transition programs. Hereinafter, such an abstract machine is called a process. In principle, the processes are independent of each other, and in principle, only messages can be used for communication. FIG. 13 shows a plurality of processes and how messages are exchanged between them. The message structure is standardized as shown in FIG. That is, each message 140 corresponds to the destination 14 of the message.
1, event 142, supplemental information 143, and sender 14
4 and each area has a fixed length. An event is an event that causes a state to exit.

The usage of this message and the characteristics of this system will be described with reference to FIG. 15 by taking a timer process having a function of timing and reporting as an example. When this process receives a message in which the destination specifies the "timer process" from another process, it registers it in the timing target 150 in the figure. The supplementary information of the message used at this time has a structure including a time interval 143a, a count value 143b, and a report event 143c, as shown in the expanded view of the figure. The timer process has the characteristic that it is activated on time. When started, the timer process changes (adds or subtracts) the count value (151) of the timing targets whose timing intervals match (151). When the limit value (0 or overflow) is exceeded (153), the elapse of time is reported to the sender (154). If there are multiple targets (155),
The processing returns to step 151 and the above processing is repeated. By doing so, the state transition program can be constructed without any interruption and suspension. Note that the time designation is performed indirectly, as described above.

Thus, they are independent of each other,
Multiple non-pause processes can physically run on a single processor. FIG. 16 shows the concept, and messages move back and forth between the processes indicated by SQ to advance the whole. The hatched portion is a control mechanism for this purpose, and can be shared by all the middle and lower processors in FIG.

FIG. 17 is a diagram showing the conceptual structure of the upper level. Since the processes are independent of each other and the messages are standardized, the waiting queues 171 and 172 are as shown in the figure.
If it is provided, the entire control can be performed. Message information taken from one waiting queue with input runs a process, the output drives the hardware at one time and is connected to another waiting queue at one time. Since such an operation is performed without suspension, the operation as a whole is consistent. This execution operation will be described later in detail.

FIG. 18 is a diagram showing a program execution level which is a condition of execution management for this purpose. A program that is activated on time by interrupting the execution of another program has the highest rank and is represented by C. In addition to this, there is a high-level program activated by an external interrupt or the like, which is represented by I. The program activated by the message resulting from these inputs has several levels, is represented by H, B, etc., and is a process mainly composed of a state transition program.

FIG. 19 shows how each program is processed. When an interrupt occurs in the processor, processing such as input scanning and clocking is performed according to the cause as shown in a of the figure. When there is no interruption, the existence is sequentially checked from the waiting queue of the highest priority as shown in b of the figure, and if there is, execution is finished and the process returns to searching again. When a certain level ends, it moves to a lower level and repeats the same thing.

FIG. 20 is a diagram showing the first half procedure of execution of the state transition program. The top-level message is fetched from the waiting queue shown on the left side of the figure, and (if in debug mode, its record is stopped) and moved to the execution area. Based on the destination (in the example of the figure), the information (process designation information) of the destination process is hierarchically obtained, and the execution of the state transition program to be executed is started.

FIG. 21 shows how the state transition program is executed. The process control information 212 and the base pointer 211 determine the task control block 213 to be used. At the same time, the start address table 215 to be referenced is determined by the process designation information 212,
Current status information 2 of the task control block 213
The start address of the macro program 217 to be executed is determined by 13c and the event in the message of the execution area 216. This is shown in the upper right of the figure, and the corresponding program display 219 is shown in the lower left. Execution mode display 21 at the top of the task control block 213
An area 3a indicates an execution mode (RUN, HALT, etc.) of the task control block.

As described above, the state transition program basically does not allow anyone to touch anything other than the message. Therefore, the state transition program can handle only the information in the execution area 216 centered on the message and the task control block 213. Then,
The processing executed by the state transition program need only be centered on the mutual operation of these data. Looking at the task control block 213 as a register and the execution area 216 as a main memory, this looks just like a simple processor. In other words, each process looks like a virtual processor. Therefore, it is easier to think of a simple command system based on this, and errors are greatly reduced. Therefore, the instructions that the state transition program can handle are limited, and this instruction is named a state transition macro.

When each process is regarded as a virtual processor in this way, various processor technologies can be used. For example, each macro instruction can set a condition code (213e in FIG. 21) after execution is completed (there is also no change). * Branch-type instructions can be provided in addition to the above arithmetic-type. * It is possible to configure a program status register that is an extension of the mode / control information. * Stack registers such as subroutines (21 in Fig. 21
3b) etc. can also be provided.

In the debug mode, as shown in the lower right of FIG. 21, the state and the macro step are left in the ring-shaped record.

FIG. 22 shows the execution of the macro. The macros are sequentially fetched (221) and processed by the corresponding execution routines (222, 223). In the debug mode, debug information is recorded (234). Then, the step counter is incremented (235), and the subsequent macro extraction processing 2 is performed.
Return to 21. After the execution of the macro program is completed, the status information is updated (236).

FIG. 23 is a table showing the system of the state transition macro. As shown in the figure, the state transition macros can be classified into add / subtract, branch system, subroutine system, timer system, multi-branch subroutine system, message sending system, and dormant system. The instruction system such as addition, subtraction, logic, and branching is no different from ordinary instructions. The message sending system is for sending messages already explained, and various indirect designations,
It has functions such as automatic designation and relay. The state transition is completed by a sleep-type instruction that specifies the state to shift to next.

When a subroutine macro instruction is used,
As a subroutine, a process having any language and function can be practically used. This is useful when the tester requires detailed operations. The following addressing is available. * Internal area of task control block * Literal
* Specific area * A certain area near address 0 In addition, direct, indirect, modification (index), etc. are possible.

Although the timer system has already been described, a reset command is required for practical processing such as an abnormal state. One of the characteristic instructions is a multi-branch subroutine instruction. It has a plurality of branches as shown in FIG. 5a. This function is as described in FIG. 23, but will be described in more detail.
The multi-branch subroutine instruction has the format shown in FIG. The execution of the favorite example is as follows. First, the instruction code at the address i is fetched, and if it is found that this is a multi-branch subroutine instruction, it branches to the subroutine branch destination S. Since it is a subroutine instruction, the macro instruction address is updated to i + 1 and stored in the stack register.
A branch is made to the subroutine of the branch destination S, but as shown in the concept of FIG. 4 and its format, usage example, and internal function in FIG. 5, a normal subroutine is applied in a program that makes a state transition. In contrast, the concept has been expanded to include functions that can include states. Further, as shown in FIG. 5, while the normal subroutine has 1 input and 1 output,
In this embodiment, it is expanded to one input and another output. In order to correspond to this return destination, in FIG. 24, four shortened addresses of branch destinations are designated so that a maximum of 5 branches can be performed.

FIG. 25 shows an instruction obtained by expanding a normal subroutine return instruction in order to deal with such a large number of returns. As shown, it has a return code that can take multiple values. When returning from the subroutine, refer to the return code. If the return code is 0, the updated address i + 1 is obtained from the stack register and returns to this address. This is the same as a normal subroutine return instruction. When the return code is 1 instead of 0, the updated address i + 1 is obtained from the stack register, and a fixed number is operated on the value entered in the return branch 1 field of the multi-branch subroutine instruction. The value added to i + 1 is returned to the address. Generally, 1 ≦ k ≦
4, when the return code is k, the updated address i + 1 is obtained from the stack register, and then a fixed number is operated on the value entered in the return branch k field of the multi-branch subroutine instruction. The value added to i + 1 is returned to the address. Therefore, in this embodiment, it is possible to branch into a maximum of 5 routes.

Conventionally, if it is assumed that such a function is normally realized, the compiler will make the matching, but in the present embodiment, it is not necessary to give the compiler a function of taking a complicated link at all. With this configuration, the compiler is simplified, the parts are commonly used, and the test scenario is easily created.

Although FIG. 21 shows the structure for executing each program in each process, FIG. 26 shows the characteristic part of the structure for executing the program common to each process. In executing the program, the execution mode display is referred to, but at this time, the task control block 21
The three common / individual indicators 213f recognize that the common program is executed. Therefore, as shown by the broken line in FIG. 26, apart from the individual start address table group 215a for each process, a common start address table group 215 accessed by the common base pointer 214 is provided.
b is provided. A part of the process designation information 212 (a field indicating only the common type) is taken out, and together with the common base pointer 214, the head address table group 215b common to that type is accessed. The macro program start address obtained as a result indicates the start address of the common macro program 217a.

As described above, the present embodiment provides the following conveniences for creating software.

* At the highest level, a scenario with a large function can be easily created with a scenario macro with a large function. On the other hand, if necessary, detailed processing can be realized by the state transition macro.

* The middle-level programs are all unified in the state transition macro, and it is not allowed to relate to anything other than the message. In addition, the whole system is hierarchically constructed as a collection of sequential machines, and each process is realized as a small single concept sequential machine. The concept of a virtual processor allows a small area to be programmed as if it were CPU intensive. These instructions have medium complexity processing capabilities and are easy to program, but in the normal case they are equivalent to programming complex capabilities. If necessary, lower-level compiler command words,
An assembler instruction word program can also be used together.

* By giving an indirect designation function to a command word such as time designation, the program becomes versatile and, in combination with the simplification of the program function itself, the diversion becomes extremely easy.

* All the interfaces are unified by standardization of the processing function configuration and messages, so that the debugging function can be used in a unified manner.

Although the embodiments have been described in detail above, all the effects result in the improvement of the program / software productivity. In this embodiment, the ratio of the original program to the finished program is about 1: 7, and the effective productivity reaches several times the common sense value. This value becomes even larger when considered at the level of the test program.

In addition, the commonality / diversity of programs is extremely high in principle, and the unification of architectures becomes easy.

At present, workstations that support SDL have come on the market as support for designing state transition programs, but when combined with this, the software productivity is dramatically improved.

[0066]

According to the present invention, the objects to be processed that are abstracted to be a sequential machine have a uniform structure,
The configuration of the program for determining the state transition and the program for the state transition can be unified and simple, and the state transition program can be extremely easily created.

[Brief description of drawings]

FIG. 1 is a block diagram showing the overall configuration of a telephone tester that is an embodiment of the present invention.

FIG. 2 is a block diagram of the entire telephone tester that also shows the processor configuration of FIG.

3 is a diagram showing a flow of execution of a test by the telephone tester of FIG.

FIG. 4 is a diagram showing a concept of configuring an entire sequential machine with blocks of a state transition program including states according to the present invention.

5 is a diagram showing the principle of macro conversion of the function in FIG.

6 is a block diagram showing a software configuration of the tester shown in FIG.

7 is a block diagram showing a hierarchical concept of an internal program of the tester of FIG.

8 is a data flow diagram showing the hardware configuration and functions of the tester of FIG.

FIG. 9 is a data flow diagram showing a specific software configuration and function of the tester of FIG.

10 is a diagram showing a state transition of a test control unit of the testing machine of FIG.

FIG. 11 is a time chart given as an example of a state transition program.

FIG. 12 is a state transition program part of FIG. 11.

FIG. 13 illustrates communication between processes according to the present invention.

14 is a diagram showing the format of the message shown in FIG.

FIG. 15 is an explanatory diagram of a function of a timer macro instruction in the embodiment.

FIG. 16 is a conceptual diagram showing the relationship between each sequential machine and the execution mechanism in the embodiment.

FIG. 17 is a diagram showing the overlap of processes in the embodiment.

FIG. 18 is a diagram showing the relationship of multilevel execution of programs in the embodiment.

FIG. 19 is a conceptual diagram of program execution control in the embodiment.

FIG. 20 is an explanatory diagram of task execution preparation according to the embodiment.

FIG. 21 is an explanatory diagram of task execution of the virtual processor according to the embodiment.

FIG. 22 is an explanatory diagram of task execution by the interpreter according to the embodiment.

FIG. 23 is a diagram showing a group of macro instructions in the embodiment.

24 is an explanatory diagram of a multi-branch subroutine macro instruction of FIG. 23.

FIG. 25 is an explanatory diagram of a subroutine return macro instruction corresponding to the multi-branch subroutine macro instruction of FIG. 24.

FIG. 26 is an explanatory diagram of a modified example of FIG. 21.

[Explanation of symbols]

DESCRIPTION OF SYMBOLS 1 ... Test procedure, 2 ... Test control part, 3 ... Telephone simulator, 4 ... Relay stand simulator, 5 ... Trunk line simulator, 6 ... Exchange under test.

Claims (16)

[Claims] 1. In a system configuration method for configuring a system including software, the software is divided into a plurality of functional parts, each functional part is configured by a sequential machine composed of a state transition program, and destination information and a state transition cause. A system configuration method characterized in that the sequential machines are connected to each other by a message to which information is attached, and each sequential machine is allowed to access only its own sequential machine and the above message. 2. The system configuration method according to claim 1, wherein the state transition program forming each of the sequential machines is described by a macro instruction. 3. The system configuration method according to claim 1, wherein the message further includes sender information. 4. The system configuration method according to claim 1, wherein all the messages have a unified configuration. 5. A sequential machine having a timing function is provided as one of the sequential machines, and the sequential machine receives a message including a time interval and a count value as supplementary information, and counts at each time interval. A system configuration method characterized in that, after the counting of the count value is completed, a message notifying that the time measurement is completed is returned to the sender as the destination. 6. The system configuration according to claim 5, wherein the sequential machine that controls the timing function is periodically activated and performs the counting only for a timing object having a timing interval corresponding to each time it is activated. method. 7. The system configuration method according to claim 6, wherein the sequential machine that controls the timing function receives a message including information specifying a timing object and cancels the timing operation for the timing object. 8. The system configuration method according to claim 2, wherein indirect addressing is adopted in the macro instruction. 9. A two-dimensional head address table for obtaining the head address of a target state transition program depending on the current state of the sequential machine and the cause of the state transition is provided, and a task control block is assigned to each sequential machine. The task control block holds the current state information indicating the current state of the sequential machine, and the sequential machine receiving the message divides the corresponding task control block from the destination information and writes it in the task control block. 3. The head address of the state transition program to be executed is obtained by searching the head address table based on the present state information and the state transition cause information of the message.
Described system configuration method. 10. A head address table shared by the plurality of sequential machines is provided, and a shared / individual indicator of the head address table is provided in the task control block. 10. The head address table according to claim 1 is referred to.
Described system configuration method. 11. A system configuration method according to claim 2, further comprising a task control block, and a macro instruction for performing operations such as addition and subtraction and logical operation using a specific memory area as an operand. 12. A system configuration method according to claim 10, further comprising a macro instruction for branching in accordance with a condition code set by the macro instruction for performing the operation. 13. A macro instruction branching to a subroutine as a kind of macro instruction.
Described system configuration method. 14. The system configuration method according to claim 13, wherein a macro instruction branched to the subroutine includes a plurality of return destinations. 15. The system configuration method according to claim 14, further comprising a subroutine return macro instruction to which a return code designating any one of the plurality of return destinations is added. 16. Each of the sequential machines is virtually regarded as a processor, and for each of the sequential machines, current state information indicating a current state, a step counter for incrementing an address of a macro instruction, a condition code, and a stack area. 3. The system configuration method according to claim 1, wherein a task control block including each of the register areas is allocated.