JPH0573302B2 - - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to a distributed packet data processing device, and particularly to a command transmission/reception method for collecting various status information of each distributed data processing module.

[Conventional technology]

Conventionally, in this type of device, as a means of collecting various statuses of each distributed data processing module, when the system management module requests the status to each data processing module, each data processing module In some cases, a procedure is taken to retrieve the status information the next time a token is passed around and return the status, and in other cases, the return of the status itself is treated as software processing of each data processing module, and the software transmits the status information. There were cases where the token was collected and sent to the system management module using normal token access.

[Problem that the invention seeks to solve]

In the conventional method described above, in the former case, it is assumed that the token is circulating normally, and if the system management module erases the token from the loop in order to stop sending and receiving packets, the sending This is impossible, and the logic of the hardware requires conflict control between the packet transmission request from the software and the packet transmission request of the hardware itself, resulting in a disadvantage of complexity.

In the latter case, the processing itself is left to the software, so if a status request is issued from the system management module as a recovery process due to a momentary power outage, software runaway may occur due to memory contents being destroyed. If the data processing module is used, the system management module cannot grasp the status of each data processing module because the status cannot be returned.

[Means for solving problems]

In the distributed packet data processing device of the present invention, the system management module transmits hardware operation information and failure information of the data processing module, hardware operation information and failure information of the mate data processing module, and software operation information of the data processing module. As a means for requesting notification to the system management module, a status request command packet, a means for forcibly transmitting the status request command packet regardless of token reception, and a means for the data processing module to send the status request command packet. It has a method in which the procedure for returning a status packet to the system management module as a response packet is configured using hardware logic.

〔Example〕

Next, the present invention will be explained with reference to the drawings.

FIG. 1 is a system functional block diagram showing one embodiment of the present invention. Reference numeral 10 denotes a 0-system system management module which has a 0-system loop management and control function. In addition, 20 0-series data processing modules 1
The 0-system data processing module n of 40 and 40 are modules for processing packet data and have exactly the same functions, and these modules are organically connected by a loop transmission path. Similarly, 11 is 1
The system management module has management and control functions for the system 1 loop. Furthermore, the 1-system data processing module 1 at 30 and the 1-system data processing module n at 50 are modules that process packet data and have exactly the same functions, and these modules are organically connected via separate loop transmission paths. The system has a dual loop configuration.
The 0-system data processing module 1 of 20 includes a 0-system packet control unit 21 consisting of hardware logic having a packet transmission/reception processing function, and a 0-system hardware 22 that displays system configuration, hardware failure information, etc. From the status register, 23 0-system soft status registers that display the software operating status or hardware minor alarm information of software detection, and 24 0-system software processing units that perform software control that processes packet data. configured.

The 1-system data processing module 1 30 is composed of a 1-system packet control section 31, a 1-system hard status register 32, a 1-system soft status register 33, and a 1-system software processing section 34. has exactly the same functions as the constituent elements of the 0-series data processing module 1 of 20.
Similarly, 40 0-series data processing modules n and 5
20 for the 1-system data processing module n of 0.
Since it has exactly the same functions as the constituent elements of the 0-series data processing module 1, the explanation thereof will be omitted here.

Before explaining the embodiment, a method of accessing the packet loop will be explained with reference to FIG. FIG. 2 is a transition diagram showing a packet transmission/reception method according to the present invention. 110, 120, 130, 14
0 are module A, module B, module C, and module D, which respectively constitute a loop system. Here, from module A of 110, 1
A method of transmitting and receiving packets to module C of No. 30 will be explained. Reference numeral 100 is a token capture operation diagram, and 110 module A having data to be sent out.
indicates that the token is first fetched. Reference numeral 200 is a data sending operation diagram showing an operation in which module A of 110, which has taken in a token, sends data to a loop. 300
is a token release operation diagram, which shows the operation in which module A 110 releases the token after completing a certain gap between packets after sending data. Reference numeral 400 is a data importing operation diagram showing an operation in which data that has passed through module B 120 and is input to module C 130 is detected to be addressed to the own module and is imported. 500
The response sending operation diagram shows an operation in which data is taken in, and after it is confirmed that the data is normal, a response is sent to module A of 110, which is the transmission source, within the inter-packet gap. Reference numeral 600 is a response capture operation diagram showing an operation in which a response that has passed through module D of 140 is input to module A of 110, is detected to be a response addressed to the user, and is captured.

As explained above, 100→200→300→
Packets are transmitted and received in the sequence 400→500→600. In this way, the response is sent at the gap between the received packet data and the token. For example, even if a packet is forcibly transmitted here regardless of the token, the same sequence as explained above is taken for sending the response.

Assuming the above packet transmission/reception processing procedure,
An embodiment of the present invention will be described with reference to FIG. 20
The 0-system system management module 10, which needs to know the various statuses of the 0-system data processing module 1 in 20, takes the token and sends a status request command packet to the 0-system data processing module 1 in 20, and after a certain period of time, Release the token. Here, if you want to execute a status request after stopping packet transmission/reception in the loop, delete the token in the 0 system management module in 10 and set the sending method to forced transmission, then you can import the token and request the status. The token is not released after sending the command packet, and only the status request command packet is output. The sent status request command packet is sent to 20 0-system data processing modules 1 through a loop transmission path.
is input. In the 0-system packet control section of 21,
It checks the header of the status request command packet, detects that it is addressed to itself, takes in the packet, and checks its normality. When it is confirmed that the packet is normal, the 22 0-system hardware status registers that hold its own operating information and failure information, and the hardware status registers displayed from the 1-system data processing module 1 of 30 that is the mate system. The contents of the 32 1-system hard status registers, which are operating information and fault information, and the 23 0-system soft status registers, which hold the software operation information set by the 0-system software processing section 24, are sequentially read, converted into packets, and converted into statuses. It is sent as a status packet in the inter-packet gap between the request command packet and the token. The sent status packets are sequentially input to the 10 0-system management modules through the loop transmission path. The input status packet is head-checked, and it is detected that the status packet is addressed to itself, and the packet is taken in and its normality can be checked. If the packet is normal, the contents of the captured packet are decoded.

〔Effect of the invention〕

As explained above, the present invention provides a status request command packet for requesting various statuses when checking various statuses of the hardware or software of each data processing module using a system management module, and sends a status request command packet as a response to this packet. By configuring the means to return the status packet containing the status of the data processing module using hardware, the operating status of the system can be grasped accurately and quickly, resulting in stable operation such as shortening the failure recovery time. A highly reliable system can be constructed.

[Brief explanation of the drawing]

FIG. 1 is a system functional block diagram of the present invention, and FIG. 2 is a transition diagram showing a packet transmission/reception system. 10...0 system management module, 11...1
System system management module, 20...0 system data processing module 1, 21...0 system packet control unit, 2
2...0 system hard status register, 23...0 system soft status register, 24...0 system software processing unit, 30...1 system data processing module 1, 31...1 system packet control unit, 32...1 system hard status register , 33...1 system software status register, 34...1 system software processing section, 40...0 system data processing module n, 50...
1 system data processing module n, 100...Token import operation diagram, 110...Module A, 120...Module B, 130...Module C, 140...Module D, 200...Data sending operation diagram, 300
. . . token release operation diagram, 400 . . . data acquisition operation diagram, 500 . . . response sending operation diagram, 600 . . . response acquisition operation diagram.

Claims (1)

[Claims] 1 A set of duplex system management modules and at least one set of duplex data processing modules are organically connected to each other by independent loop transmission paths, and packet access is In a distributed packet data processing device having a token passing method, the token is released after a certain period of time after the packet is sent, and the response packet to the packet is returned within the packet interval between the packet and the token. The system management module has a function of forcibly deleting and generating tokens from within a loop, a function of transmitting the packets without token control, hardware operation information and failure information of the data processing module, and mate system data processing. The data processing module has means for requesting at least one or more of the module's hardware operation information and failure information, and the software operation information of the data processing module in a status request command packet; , a function of holding the hardware operation information and failure information or the software operation information, a function of importing the held hardware operation information and failure information of the mate data processing module, and a function of the status request command packet. At least one of the hardware operation information and failure information of the data processing module, the hardware operation information and failure information of the mate data processing module, and the software operation information of the data processing module as a response packet of the 1. A command transmission/reception method for a distributed packet data processing device, characterized in that the command transmission/reception method for a distributed packet data processing device is characterized in that it has a configuration method in which a means for returning the contents of a status packet as a status packet is configured using hardware logic.