JPS58155459A - Interface system for inter-program input/output buffer - Google Patents

Abstract

PURPOSE:To easily decide the influence and suitability when changing a design of a program, by fetching and processing a data from an exclusive buffer by a receiving instruction, and sending out a result data to a buffer of other program by a transmitting instruction. CONSTITUTION:Each task 2a-2c inputs an input data from task exclusive input/output buffers 122-12c, respectively, by a receiving instruction 8 from a data delivery control routine 11, and sends out an output data to the buffers 12a-12c by a transmitting instruction 9. These instructions 8, 9 transfer only the name of a task to each task, and an address of input/output data is decided in accordance with an inter-task interface related diagram in which the control routine 11 is designed in advance. The control routine 11 decides the address, and after that, stores the input/output data in the address area of a buffer 12 corresponding to a designated task. In this way, the input and output of these buffers 12 is executed by the data control routine.

Description

DETAILED DESCRIPTION OF THE INVENTION The present invention relates to a program-to-program input/output buffer interface method, and particularly to a data flow type interface method in which data is exchanged between programs using a dedicated buffer in order to facilitate software design management. .

A technique for proceeding with design using a computer system, that is, C
Programs are also included as targets of AD.

When designing software using computer control, the design manager first designs a table to be shared between programs.
Next, the program structure is determined, and each person in charge designs the program.

However, when designing using this procedure, when each program is changed, etc., it is self-managed by each corresponding person, but since there is no person in charge of the table between programs, the design manager is responsible for the changes that occur from the document to the object. Changes can be well managed.

FIG. 1 is a diagram showing a conventional program-to-program input/output interface system.

Conventionally, a startup management method has been used, and in this method, as shown in FIG. The input data necessary for the processing is read from (R@&(17)). Next, the output data of the processing result is written to the shared table 3 (Wrlt.6).

Thereafter, l+ND51 is issued in order to notify the startup management routine 1 of the end of the process.

In the conventional method shown in Figure 1, the administrator has to
It only manages the start and end of processing of tasks 2b and 2.Each task 2m+2br2e can be written to or read from any location in the shared table 3. be. Therefore, when a design change occurs in a specific task 2 and the structure or contents of the shared table 3 is changed, other tasks 2 that need to be modified due to the change
[Difficult to identify. Furthermore, even if the change is necessary for an individual program, it is difficult to judge whether it is appropriate for the entire system. in this way,
In the conventional method, data is exchanged between tasks 2 a + 2 b y 26 via shared table 3, and since each task 2 can arbitrarily change the contents of table 3, it is difficult to actually At the debugging stage, it is difficult to distinguish between the ranges of changes (1 to 11m), and a lot of time is wasted on debugging.

The purpose of the present invention is to overcome these conventional drawbacks by providing a four-gram inter-gram input/output buffer that can determine whether changes in the design of each program are appropriate for the entire system.・Providing an interface method.

Top t! In order to achieve the purpose, the four-gram human output buffer interface method of the present invention is designed to integrate a task and a table, and makes the table (hereinafter referred to as a buffer) belong to a specific task. The entire feature is that data passing through this buffer is managed not only in program documents or rules, but also during execution.

The operating principle and embodiments of the present invention will be explained below with reference to the drawings.

FIG. 2 is a diagram illustrating the operating principle of the program-to-program input/output interface system of the present invention.

As shown in the second @I, in the present invention, each task 2a+2
Corresponding to b12a, task-specific cover 7a12a
s 12 b * l 2 o for each program! All data necessary for a row is taken out from a buffer 12 dedicated to that program and processed, and all output data as a result of the processing is sent to a buffer 12 of another program determined by a data transfer management routine 11. That is, in FIG. 2, each task 2m+2b, 26
The input data necessary for IJIJllI and the output data as a result of processing are received via a specific buffer 12 through a data transfer management routine pipe.

Each task 2 m + 2 % e 2 receives data and receives a reception command (R11 (IIV)) from the management routine 11.
8 buffers the input data 12 m * 12
b * 12 Take in from a (Rs & direct 7), transmit command (s: gy19 to buffer output data 712m,
12b* Send at 12° (Write 6).

These instructions 8.9 only send the task name to each task, and the addresses of input and output data are determined by the data transfer management routine 11 according to the inter-tastor interface relation diagram designed in advance. 6. After determining the address, the management routine 11 inputs the address and address of the tasker dedicated input cross 7T12 corresponding to the specified task.
Store input/output data in the area (Writ・6).

In this way, you can create a dedicated human cover for these tasks.
The data transfer management routine executes input/output to/from (R@ad/Writ.).

3rd W7! J is an equipment configuration diagram of a railway power management system showing an applied side of the present invention.

The 0PU 16 of the computer system 16 uses a processor display 17, a legging typewriter 18, and a power management operation panel 22 as display/recording devices. Also, 0
When storing large-capacity data, the PU 16 uses the magnetic disk storage device 19 as a secondary storage device.

The dispatcher inputs the command from the power management operation lock, and the received command input is sent to the input/output relay board 21 [through OFυ
Sent to 16th. The output from the computer system 16 is sent to the remote monitoring and control devices 23 and 24 through the Bricess input/output device t20 and the input/output relay board 21.

There are two coupling methods for remote monitoring and control devices: 1:1 and 1:N, and the device 23 using the former method is connected to the substation 2.
5, so the control device @23 is provided only in the substation 25, whereas the device 24 using the latter method controls all *WIN electrical equipment and room 26 in parallel. One outfit! It is sufficient to provide only 2+l.

Figure 14 shows the st! of railway power management software in the 3rd WJ. j[ess is V to be explained.

FIG. 4 shows TASTA Sakaki, which realizes the functionality of software for a dispatcher to centrally control equipment in each substation, electrical room, and switchyard.

The command force 31 is by the command staff! It is a jokkankai dankomi taska by pressing the button on the control board, and the command content is α)
There is a display request for [1st execution, 2nd needle stroke change]. α), check control calculation from command input (31) 0
After calculating the control procedure tUt in step 4) and checking whether the current state of the equipment allows this -11F, the control output O
0 to the direction monitoring and control device.

After the control output, in order to confirm whether the local equipment is working, data is imported from the remote control device and the current status of the equipment is created (c38), and this current status (38) and control output e5)
(Noro) to confirm operation. The verification result data is sent to the control calculation check task 34, and processing 1 is performed when one of the control procedures is completed. In the case of 2) above, the schedule is modified by the command input (31), the control procedure is calculated and checked, and the control output S0 is monitored and controlled. Send to device. In this case as well, perform the genzawa kaku m in the same way as before. Next, in case 8), a display is required to check the operating status of the equipment, and the dispatcher's manual ■
1) Edit the monitor data # (45), 01
Regardless of the display method and command input, current status creation No. 8)
In order to analyze the current situation later, the so-do pipe [(39'l, t1
Analysis (40), draft revision IEI (41), mpower ii thousand 1
There is a method of editing and outputting each display or recording device after all tasks in 1 (42) and schedule review (43) have been executed. If the present invention is applied to FIG. 4, the data required for each task is extracted from the buffer dedicated to each task, processed, and sent to the buffer dedicated to other tasks determined by the data transfer management routine. Influence range I in case of envy of the establishment of Pudaram! Meet briefly'lII
m! At the same time, it is possible to fully judge whether the design change is appropriate for the entire system. FIG. 6 is a diagram illustrating a method for executing an interface collective management routine according to an embodiment of the present invention.

In the present invention, the data transfer management routine [To be executed, an area for an output data table, constants for transmission and reception commands, and a buffer table as shown in FIG. Each is stored in the order of operation.

The sending task 61 and the receiving task 52 are assigned, and first, the sending task 51 writes the sending data to the output data table on the main memory IP 50 (Write).

Next, the send task 551 calls the send(II)fXl) routine (0mXIL(A))Ill.The parameter at this time is the send value task number (4). The sending routine searches the sending/receiving wIWk from the task number (4) to find the corresponding buffer number t, and transfers the contents of the output data table to that buffer. moreover,
A start command (Q
UIU) t-issue. The receiving task 52 is a starting bale.
Receive (11011
v) Call the routine (OA I, L (B)).

The reception routine uses the transmission and reception constants from the parameter task number (B) to transfer data from the buffer it to the variable area of the reception task 52 to the buffer it uses.

FIG. 6(&) is a four-dimensional layout diagram of a main memory device showing a first embodiment of the present invention.

The area other than the OS (Op@ratimg5yst@m) program and Os table is the user area.

This user area is divided into five parts.

That is, α) Common subroutine area, Groupal table area, G5) Application program area, Buffer table area, G5
) is the output data table area.

The above area α) contains the ink 7 ace management subroutines for transmission (81ND) and reception (it) shown in FIG.
xazv) is in the mold. In addition, area 2) of -h includes transmitting/receiving settings Wk, and area 0) includes:
Contains programs for each task of sending and receiving. (
A buffer table (transfer) is provided as a new route to the reception task 52, and its contents include a data management section consisting of a read l-inter, a write l-inter, and a *V number, and data are stored therein. This buffer table is the sixth [1(1
As shown in FIG. 1, it is a sibling buffer, and data is stored in the space between the write pointer and the read linter, and each pointer scores the sigitalizer. As shown in No. 6 N (6), the output data consisting of the destination task name and the data body is stored in the fourth area for the number of sending tasks 51 (4). That is, an area for one Tagata data is prepared for each transmission task in the Oka data table.

In this way, since the data necessary for running a task is collected in one table, test data can be set to I'll during the debugging stage of software production. In addition, the data exchange process becomes visible and easy to monitor, which is convenient during the debugging stage.

As explained above, according to the present invention, a dedicated receive buffer is provided for each program, and each program retrieves and processes data from the dedicated receive buffer in response to the receive command of the data transfer management routine. Since the result data is sent to the reception buffer of the intermediate program determined by the transmission command, the software management system consisting of the program and the table can be managed at any level of detail, and therefore the scope is not affected by changes in program design. In addition to being able to easily understand the design changes, it is also possible to judge whether the method of design change is appropriate for the entire system.
It is also necessary to accurately estimate the amount of work required for changes.

[Brief explanation of the drawing]

FIG. 1 is a diagram showing a conventional program-to-program data interface method, FIG. 2 is a diagram of the operating principle of the program-to-program data interface method of the present invention, and FIG. 3 is a diagram of a railway power management system showing an application example of the present invention. 4 is a diagram showing an outline of the software in FIG. 3, FIG. 3 is an explanatory diagram of an execution method of an interface execution management routine showing an embodiment of the present invention, and FIG. 6 is a diagram showing an embodiment of the present invention. FIG. 2 is a program layout diagram of the main storage device shown in FIG. 2' e 2 br 2 a 1 task, 61 writes, 7
Lots of them, 8I reception command, 98 transmission command, 12&, 12b
, 12o: Taster dedicated input/output x 7a, 60: Main memory, 51 = Sending task, 62! Receive task. Figure 1 Figure 6 (a) OS block area OS table, rear view. Puruchin REcnv 5END Group - 1, Nirab Program? (b) Screen-'-1/T7 T-ta writing pointer

Claims (1)

[Claims] A dedicated input/output buffer is provided for each program, and each program retrieves all data from the dedicated input/output cover 77a according to the receive command of the data transfer management routine, processes it, and transfers the processed data to the data transfer management routine. An inter-program input/output buffer interface method characterized by sending data to a dedicated input/output buffer of another program determined by a sending command.