JP4821715B2 - Equipment management communication system - Google Patents

Description

  The present invention makes it possible to connect a managed device to a management apparatus connected via a communication network separately from the communication network and perform at least one of monitoring and control of the managed device via the communication network. The present invention relates to a device management communication system.

  Conventionally, when managing a large number of managed devices (at least one of monitoring and control) using a communication network, a lower communication network is constructed with the type and location of the managed device as a unit. It is considered that the communication network is managed by an upper communication network. In order to construct such a hierarchical communication network, as shown in FIG. 8, local management devices 1a to 1c are provided in the lower communication networks (hereinafter referred to as “lower nets”) Nsa and Nsb. The managed devices 2a and 2b are managed by the management devices 1a to 1c. In the upper communication network (hereinafter referred to as “upper net”) Nm, the local management devices 1a to 1c serve as terminals, and the global management device 3 manages the local management devices 1a to 1c.

  In the illustrated example, a managed device 2a such as a lighting fixture or a switch constructs a lower net Nsa together with the local management device 1a, and a managed device 2b such as a measuring instrument for measurement and measurement uses the lower net Nsa together with the local management device 1b. Nsb is constructed. The lower nets Nsa and Nsb operate autonomously. For example, in the lower net Nsa provided with the managed device 2a, the lighting fixtures can be turned on / off according to the operation of the switch without using the upper net Nm. It is possible.

  Also, in the illustrated example, the managed devices 2a and 2b are not connected to each area E1 and E2 in order to manage the managed devices 2a and 2b in units of areas E1 and E2 including a plurality of lower nets Nsa and Nsb. A local management device 1c is provided. The local management device 1c can communicate with the local management devices 1a and 1b in the areas E1 and E2, and integrates and manages information managed by the local management devices 1a and 1b in the areas E1 and E2. .

  On the other hand, the global management device 3 provided in the upper network Nm treats the local management devices 1a to 1c as terminals, and the global management device 3 exchanges information on the managed devices 2a and 2b through the local management devices 1a to 1c as an intermediary. . The global management device 3 includes one or more computers.

  The local management devices 1a to 1c are different in operation but have the same basic configuration. Therefore, the local management devices 1a to 1c will be described as the local management device 1 unless otherwise distinguished.

  In the local management device 1, information acquired from the lower nets Nsa and Nsb is transmitted to the global management device 3 via the upper net Nm, and an instruction acquired from the global management device 3 through the upper net Nm is transmitted to the lower nets Nsa and Nsb. To reflect. Further, information is exchanged between the local management devices 1 using the upper network Nm.

By the way, the communication protocol used in the upper network Nm is hierarchized similarly to the OSI reference model. The IP protocol is used as the network layer, and the BACnet (A Data Communication Protocol for Building Automation and Control Networks) protocol is used as the upper layer protocol. Has been proposed (see, for example, Patent Document 1). As shown in FIG. 9, the BACnet packet used in the BACnet protocol has an Ether (registered trademark) header HD1, an IP header HD2, a UDP header HD3, a BVLL header HD4, and a BACnet area BAC. It corresponds to the port layer, session layer, and upper layer (BACnet protocol). The BACnet area BAC is an area for storing BACnet protocol data. The BACnet area BAC includes a device ID for identifying each local management apparatus 1.
JP 2007-96539 A

  By the way, in order to communicate between the local management devices 1 in the higher-order net Nm, it is necessary to know each other the local management devices 1 that can communicate in the higher-order net Nm. The IP address and device ID in the upper net Nm change dynamically. In a large-scale device management communication system, since the number of local management devices 1 increases, it is difficult to deal with such dynamic changes manually.

  In contrast, in a communication network employing BACnet, whether or not communication is possible is confirmed by sending and receiving packets called WhoIs and IAm, and the IP address and device ID of the communicable local management device 1 are acquired. Therefore, it is possible to dynamically manage the IP address, device ID, and communication state (communication availability) for the local management device 1 capable of communication.

  However, since each local management device 1 has only one state management table for registering an IP address, a device ID, and a communication state, when trying to communicate with another local management device 1, the local management device 1 Communication cannot be started unless it is determined whether or not communication is possible for one IP address and device ID, and there is a problem that a wasteful determination is made each time communication is performed.

  The present invention has been made in view of the above reasons, and an object thereof is to provide a device management communication system that prevents useless processing at the start of communication by registering only a management device capable of communication. There is.

  The invention of claim 1 is a device management system having a communication network in which a plurality of management devices are connected, and a managed device connected to at least one management device separately from the communication network. The apparatus includes a communication unit that communicates with another management apparatus using the hierarchized first protocol and the second protocol, and another management apparatus capable of communication up to the second protocol that is a higher layer than the first protocol. A communication status check that sends out an existence confirmation packet to be inquired and returns a reply packet including the first address used in the first protocol and the second address used in the second protocol to the source of the existence confirmation packet when the existence confirmation packet is received A state management table in which a first address, a second address, and a communication state indicating communication availability are registered in association with each other, and a first address And an address table in which a management index associated with each of the data in the state management table is registered in association with each other, and a first address capable of communicating in a communication state among the management devices registered in the state management table And a table management unit that extracts and stores the second address in the address table, and the communication unit uses the first address and the second address registered in the address table when communicating with another management device. It is characterized by.

  According to a second aspect of the present invention, in the first aspect of the invention, the communication status confirmation unit is configured such that a management index corresponding to a first address included in a packet received through the communication unit is not registered in the address table. The existence confirmation packet is transmitted through the communication unit.

  According to a third aspect of the present invention, in the first or second aspect of the present invention, the table management unit is configured such that at least one of a first address and a second address included in a reply packet received through the communication unit is the address table. The contents of the corresponding data in the state management table and the address table are replaced with the contents of the reply packet only when the communication state of the state management table associated with the management index is not possible in communication. It is characterized by that.

  According to a fourth aspect of the present invention, in the invention according to any one of the first to third aspects, the table management unit has at least one of the first address and the second address included in the reply packet received through the communication unit. When the communication state of the state management table that is already registered in the address table and related by the management index is pending, the content of the reply packet is added to the state management table.

  According to the configuration of the first aspect of the present invention, each management device verifies whether or not communication is possible up to the second protocol of the upper layer using the survival confirmation packet. I can grasp it. In addition, in each management device, in addition to the state management table for managing the communication state, the first address and the second address are registered in the address table only for the management device capable of communication. It is guaranteed that the first address and the second address belong to a management apparatus capable of communication, and a process for verifying whether communication is possible before communication is started becomes unnecessary. Further, since the data registered in the address table is related to the data in the state management table by the management index, when the first address or the second address of another management apparatus is changed, or in the communication network When a new management device enters, it is possible to easily determine whether it is already registered or not registered depending on the presence of a management index, and it is possible to determine whether to overwrite or add data.

  According to the configuration of the second aspect of the present invention, if the management index is not registered when the received packet is checked against the address table, it can be determined that the management device has newly entered the communication network, so the survival confirmation packet is transmitted. As a result, the first address and the second address can be acquired for the newly entered management device.

  According to the configuration of the invention of claim 3, the state where only one of the first address and the second address matches occurs when the setting of the management apparatus is changed, but only by replacing a corresponding set of data. Since other data is not affected, the setting can be changed without affecting communication with other management apparatuses.

  According to the configuration of the invention of claim 4, even if a management device that is not used immediately at the time of system construction is connected to the communication network in advance due to installation work or the like, the setting contents regarding other management devices are changed. Since it is not necessary, the system is not damaged and the degree of freedom in construction can be increased.

  In the present embodiment, a device management system having the configuration shown in FIG. 8 will be described as an example. As shown in FIG. 1, the local management device 1 as a management device in the communication network includes a first communication unit 11 connected to the transmission line Lm of the higher-order net Nm and a first communication unit 11 connected to the transmission line Ls of the lower-order net Ns. 2 communication unit 12. The protocol used in the first communication unit 12 is hierarchized like the OSI reference model.

  A BACnet packet having the format shown in FIG. 9 is used for a packet transmitted through the upper network Nm. In the BACnet packet, the IP header corresponds to a network layer protocol (first protocol), and the BACnet area corresponds to an application layer protocol (second protocol). The IP header includes an IP address (first address), and the BACnet area includes a device ID (second address) for individually identifying devices in the BACnet. Accordingly, it is required to set the IP address and the device ID so that they do not overlap in the upper net Nm. In the present embodiment, the IP address is associated with the first address and the device ID is associated with the second address. However, the first address and the second address may be associated with addresses in other layers.

  The local management device 1 is provided with a communication status confirmation unit 13, which communicates with “WhoIs” for confirming whether communication with other local management devices 1 connected to the higher-order network Nm is possible. A BACnet packet (hereinafter referred to as “survival confirmation packet”) is sent to the first communication unit 11 at a predetermined timing (usually at a constant time interval of about 1 minute). Note that “communicable” includes not only communication by the first protocol but also communication by the second protocol. In short, the existence confirmation packet inquires whether communication to the upper layer is possible.

  When the communication status confirmation unit 13 receives a survival confirmation packet from another local management device 1, the communication status confirmation unit 13 transmits a survival confirmation packet to the local management device 1 that has transmitted the survival confirmation packet, and BACnet referred to as “IAm”. A packet (hereinafter referred to as “answer packet”) is transmitted to the first communication unit 11. The existence confirmation packet is transmitted by broadcast (broadcast), and the response packet is transmitted by unicast. The BACnet area of the reply packet includes at least IAm data having information on the device ID and the communication state.

  The communication state that the communication state confirmation unit 13 returns as a reply packet is “survival” indicating a communicable state. The local management device 1 includes a table management unit 14, and the table management unit 14 of the local management device 1 that has transmitted the survival confirmation packet cannot obtain a reply packet from the local management device 1 that has been “alive” in the past. In this case, the communication state of the local management device 1 is determined as “leave”. This corresponds to a case where the local management device 1 whose communication state is “leave” cannot communicate and the local management device 1 is disconnected from the higher-order network Nm or cannot communicate. When the local management device 1 intentionally leaves the upper network Nm, a packet indicating “leave” is transmitted by broadcast to notify each local management device 1.

  The local management device 1 includes a state management table Tb1 having an array structure in which the IP address, device ID, and communication state of the local management device 1 included in the upper net Nm are stored in association with each other, and the local management device included in the upper net Nm. 1 is provided with an address table Tb2 having a list structure in which IP addresses and device IDs are registered in association with each other only for the local management device 1 capable of communication. The device ID and the communication status in the status management table Tb1 are handled collectively in the same manner as the IAm data included in the reply packet (that is, one item in the form of device ID + communication status). The contents of the state management table Tb1 and the address table Tb2 are generated based on the device setting file when the system is started, but are updated according to the presence / absence and contents of a reply packet for the survival confirmation packet during the operation of the system.

  The device setting file is set in the global management apparatus 3. That is, by setting the IP address and device ID of each local management device 1 in advance and generating a device setting file, the device setting file is distributed from the global management device 3 to each local management device 1, and each local management device 1 The state management table Tb1 and the address table Tb2 are generated. Further, the device setting file may be distributed from the global management apparatus 3, or the local management apparatus may have a temporary device setting file in advance.

  A procedure for updating the contents of the state management table Tb1 and the address table Tb2 based on the presence / absence and contents of a reply packet for the survival confirmation packet will be described later.

  As shown in FIG. 2A, the state management table Tb1 includes items of IAm data (device ID + communication state) and an IP address. The device ID is described in the form of “dev- *” (* is a number) in the IAm data of the state management table Tb1. The transmission line Lm of the upper net Nm is wired, and in principle, all the local management devices 1 connected to the upper net Nm can communicate with each other. Accordingly, the state management table Tb1 and the address table Tb2 of each local management device 1 include the IP addresses of all the local management devices 1 included in the upper net Nm.

  However, there are cases where the local management device 1 newly enters the upper net Nm, the local management device 1 is removed from the upper net Nm, or the local management device 1 fails. In the former case, it is necessary to add the local management device 1 capable of communication to the state management table Tb1 and the address table Tb2. In the latter case, the state management table Tb1 indicates that communication is disabled and the address In the table Tb2, it is necessary to delete the local management device 1 that has become unable to communicate. The communication state when newly entering is “survival”, and the communication state when communication is disabled is “leave”.

  As will be described later, since the state management table Tb1 adopts an array structure in order to specify the position in the state management table Tb1 for each set of data in the state management table Tb1, the state management table Tb1 The capacity required to build the system is secured in advance with an allowance.

  As shown in FIG. 2B, the address table Tb2 includes items of IP address, device ID, management index, number of transmissions, and transmission time. The management index is an index for referring to each set of data in the state management table Tb1, and indicates the order in which the related data is included in the state management table Tb1. For example, data whose management index is “2” in the address table Tb2 is related to the second (second line in the illustrated example) data of the state management table Tb1.

  The number of transmissions and the transmission time are values for specifying the upper limit number of times of transmitting the survival confirmation packet and the time interval for transmitting the survival confirmation packet, respectively. In this case, or when the transmission time is longer than the set value from the previous transmission of the survival confirmation packet, the survival confirmation packet is transmitted. Therefore, the communication status confirmation unit 13 has a counter function for counting the number of transmissions and a clock function for limiting the transmission time. Although not shown in the figure, the address table Tb1 has a list structure, and therefore includes data representing the connection before and after each set of data. By adopting a list structure for the address table Tb2, it is easy to add and remove data in the address table Tb2.

  The table management unit 14 registers the IP address and the device ID in the address table Tb2 for only the local management device 1 whose communication status is “alive” among the local management devices 1 stored in the status management table Tb1. At this time, a management index is also given.

  The first communication unit 11 uses the IP address and device ID registered in the address table Tb2 when communicating with another local management apparatus 1. Since the address table Tb2 does not include data whose communication state is “leave”, there is no wasteful communication with the local management device 1 whose communication state is “leave”, and the processing and communication are not performed. There is no waste. In other words, since the local management device 1 registered in the address table Tb2 is communicable, if the local management device 1 registered in the address table Tb2 is selected and communicated, the local management incapable of communication is possible. There is no wasteful process of specifying the device 1. This is particularly effective when a large number of local management devices 1 are provided, and traffic on the upper net Nm is reduced by not performing unnecessary processing and communication.

  The operation of the local management device 1 will be described with reference to FIG. In each local management device 1, when a BACnet packet (survival confirmation packet or reply packet) is received through the first communication unit 11 (S1), the IP address of the source of the BACnet packet (hereinafter simply referred to as “packet”) from the address table Tb2 A device ID corresponding to the address is searched (S2). When the device ID corresponding to the received IP address is not registered in the address table Tb2 (S3: No), the acquired IP address is stored in the address table Tb2, but the device ID is a temporary ID indicating that it is an unknown device. A device ID is assigned, and an appropriate value corresponding to unregistered management index is assigned (S4). As the temporary device ID, an unused one of values not used as the device ID is used. Thereafter, it is determined whether or not the received packet indicates “survival” (S5).

  The location where data is newly registered in the address table Tb2 may be at the end of the address table Tb2. However, since the address table Tb2 has a list structure, it is inserted at an appropriate location so that IP addresses, device IDs, and the like are arranged in ascending order. It is also possible to do.

  When the device ID has been registered in step S3 (S3: Yes), it is confirmed whether or not the device ID is a temporary device ID (S8), and further confirmed whether or not the received packet indicates “survival”. (S5, S9). In both cases of steps S5 and S9, when the received packet indicates “survival” (S5: Yes, S9: Yes), the process shifts to the device registration check process (S6), and then shifts to the registration update process. (S7). Device registration check processing and registration update processing will be described later.

  In short, when a device ID (may be a temporary device ID) exists in the address table Tb2 and the received packet indicates “survival”, a device registration check process (S6), a registration update process (S7), I do.

  On the other hand, if the received packet does not indicate “survival” (that is, if it is a survival confirmation packet), the device ID is a temporary device ID (S5: No), and further, If the transmission condition is satisfied, a survival confirmation packet is transmitted (S10). The transmission condition of the survival confirmation packet is that when there is data in which the management index is not registered even though the IP address and the device ID are registered in the address table Tb2, the number of transmissions of the survival confirmation packet is the address table Tb2. If the value is equal to or less than the value set in, one of the cases where the time equal to or longer than the set value of the transmission time has elapsed since the survival confirmation packet was transmitted is established.

  In step S10, when the received packet does not indicate “survival” in the reply packet and the management index does not exist in the address table, it is considered that the new local management device 1 has entered the upper net Nm. The confirmation packet is transmitted by broadcasting, and the answer packet is transmitted to the newly entered local management apparatus 1. With this operation, the IP address and the device ID can be detected for the newly entered local management device 1. In FIG. 3, the process of returning the reply packet when the survival confirmation packet is received is omitted.

  By the way, as described above, when the device ID exists in the address table Tb2 and the received packet indicates “survival”, the device registration which is step S6 in FIG. 3 is performed using the IP address and IAm data acquired by the reply packet. Perform check processing. In the device registration check process, as shown in FIG. 4, the following processes are sequentially performed on all data registered in the address table Tb2. That is, the following processing is performed for each set of data in the address table Tb2.

  First, for the IP address and device ID, it is determined whether the data of the received reply packet matches the data registered in the address table Tb2 (S1), and if both match or one matches, It is determined whether or not a management index is registered (S2, S3). If the IP address matches the device ID and the management index is registered (S2: Yes), the device registration check process is terminated because the data is already registered in the address table Tb2.

  When the IP address and the device ID match the data of the received reply packet and the data registered in the address table Tb2, but the management index is not registered (S2: No), the registration update process ( The process proceeds to step S7) in FIG. This operation corresponds to a state in which the state management table Tb1 and the address table Tb2 are not associated with each other immediately after the above-described device setting file is distributed from the global management apparatus 3. The association between the state management table Tb1 and the address table Tb2 is performed by exchanging subsequent survival confirmation packets and reply packets.

  When only one of the IP address and the device ID included in the received reply packet matches in the data of interest in the address table Tb2, and the management index is registered (S3: Yes), the IP address and the device ID Therefore, the communication status is acquired from the status management table Tb1 using the management index (S4).

  Here, if the acquired communication state is “survival” (S5: Yes), updating of the set of data of interest in the address table Tb2 is prohibited (S6), and the device registration check process is terminated. If the acquired communication state is “leave” (S5: No), the process proceeds to a registration update process (step S7 in FIG. 3).

  When the management index is not registered in step S3 (S3: No), or when both the IP address and the device ID included in the received reply packet do not match the data of interest in the address table Tb2. (S1), the IP address of the reply packet is compared with the device ID for the next data in the address table Tb2. If neither the IP address nor the device ID included in the answer packet is registered in the address table Tb2, it is considered that the local management apparatus 1 that is the sender of the answer packet newly joins the upper network Nm. It is done.

  The above operation is repeated until the last data in the address table Tb2 until the device registration check process is completed or the process proceeds to the registration update process. When the device registration check process is completed under the above-described conditions, the next packet is awaiting reception without performing the registration update process.

  Next, the registration update process corresponding to step S7 in FIG. 3 will be described. In the registration update process, data is registered in the state management table Tb1 or data in the state management table Tb1 is updated based on the contents of the reply packet. Thereafter, the data in the address table Tb2 is updated.

  In the registration update process, as shown in FIG. 5, first, the following processes are sequentially performed on all data registered in the state management table Tb1. In the registration update process, first, the IP address and device ID of the reply packet are compared with the IP address and device ID registered in the state management table Tb1 (S1). Here, the subsequent processing differs depending on whether at least one of them matches or both do not match.

  If at least one of them matches, it is determined whether or not the communication state is “leave” (S2). If it is “leave” (S2: Yes), it is determined whether the match is the first time or the second time or later ( S3). When it is the first time (S3: Yes), this is preferentially used to update the corresponding data in the state management table Tb1 (S4). However, if it is the second or later match (S2: No), the corresponding data in the state management table Tb1 is deleted (S5). As a result of this processing, only the upper data remains in the order registered in the state management table Tb1, and other data is deleted. Therefore, when the IP address or device ID is duplicated, one piece of data that is not duplicated. Only will remain.

  Next, regardless of whether or not there is a match in step S1, it is determined whether or not the focused area (area of the unit to which the management index is assigned) in the state management table Tb1 is a free area (S6). If so (S6: Yes), the location is stored (S7).

  After the above processing is performed for all data registered in the state management table Tb1, the match between the IP address and the device ID is confirmed again (S8). When the free area of Tb1 is stored, the IP address and IAm data obtained in the reply packet are registered in the free area. If there is no free area in the state management table Tb1, the end of the state management table Tb1 is registered. The IP address and IAm data obtained in the reply packet are registered (S9).

  As in steps S5 and S9 in FIG. 5, in the state management table Tb1, if there is an overlap in the IP address or device ID, it is deleted, and when a free area is created by the deletion, new data is written in the free area. In the state management table Tb1, when the communication state included in the IAm data is “leave”, it is treated as an empty area. As described above, by overwriting data using the empty area in the state management table Tb1 having the array structure, the storage area used as the state management table Tb1 can be effectively used.

  Through the processing so far, the communication status is registered as “alive” in the status management table Tb1 with respect to the transmission source of the reply packet. After the data is registered in the state management table Tb1 in this way, the contents of the address table Tb2 are updated. That is, for the address table Tb2, each data is sequentially extracted from the head to the tail, and the following processing is performed on each data.

  That is, the match between the IAm data and IP address registered in the state management table Tb1 and the IP address and device ID of each data in the address table Tb2 is verified (S10). It is determined whether the first time or the second time or later (S11). If the first match is found (S11: Yes), the set of data focused on in the address table Tb2 is updated (S12). On the other hand, if it is the second time or later, the data of interest in the address table Tb2 is deleted (S13). That is, when the IP address or device ID is duplicated in the address table Tb2, only one piece of data without duplication remains. In short, like the state management table Tb1, the IP address and the device ID are arranged so as not to overlap each other.

  Next, regardless of whether or not there is a match in step S9, it is determined whether or not the area of interest in the address table Tb2 is a free area (S14). If it is a free area, the location is stored (S15). .

  After performing the above-described processing for all data registered in the address table Tb2, the IP address and the device ID are reconfirmed again (S16). When a free area is stored, the IP address and device ID are registered in the free area, and if there is no free area in the address table Tb2, the IP address and device ID are registered at the end of the address table Tb2 (S17). ).

  On the other hand, if it is “leave” in step S2, the communication state is registered with “hold”, and if there is a communication state with “hold” (S19: Yes), it overlaps with the device ID. The device ID is rechecked (S20). If the communication state of the re-checked device ID is “leave” (S21: Yes), after overwriting (replacement) with the “leave” (S22), the process proceeds to step S6. Note that if there is no “hold” in step S19 or there is no “leave” in step S21, the process proceeds to step S6.

  According to the above procedure, when the reply packet is received, the communication state registered in the state management table Tb1 is “alive”, and when it is “alive”, the same IP address and device ID are the addresses. It is also registered in the table Tb2. In other words, if the IP address and the device ID are registered in the address table Tb2, it means that the communication state is “alive” in the state management table Tb1.

  As described above, even when the IP address or device ID of the local management device 1 is changed or the local management device 1 is replaced, the state management table Tb1 and the address table Tb2 are automatically updated. Therefore, it is not necessary to make a new setting, and it becomes possible to respond quickly to the change without hindering the operation of the upper net Nm.

  Based on the above-described operation, a change in the contents of the state management table Tb1 and the address table Tb2 according to the contents of the received answer packet is illustrated. Assume that a reply packet including the information shown in FIG. 6A is received and the address table Tb2 at that time has the contents shown in FIG.

  First, the case where the newly connected local management device 1 is the transmission source of the reply packet will be described. In this case, the IP address and device ID of the reply packet do not exist in either the state management table Tb1 or the address table Tb2. Therefore, as shown in FIG. 6C, first, the IP address (2001 :: 3) obtained from the reply packet is registered at the end of the address table Tb2 by the processing shown in FIG. Is assigned a temporary device ID (0x3FFFFF). Further, since the information is not registered in the address table Tb2, a value (0xFFFF) indicating unregistration is also registered in the management index (S2 → S3 → S4 in FIG. 3).

  Next, when the device registration check process is performed, a matching IP address is registered in the address table Tb2 with respect to the IP address and device ID of the reply packet, but the device ID is a temporary device ID and does not match. Furthermore, since an unregistered value is registered in the management index, the process proceeds to a registration update process (S1 → S3 in FIG. 4).

  Further, since there is no data that matches the content of the reply packet in the state management table Tb1, a “mismatch” determination is made in step S1 of FIG. 5, and the IAm data (device ID and data) received by the reply packet in the state management table Tb1. Communication state) and IP address are registered, and the content is as shown in FIG. In the illustrated example, data corresponding to the contents of the reply packet is registered at the end of the state management table Tb1.

  In the registration update process, after the data is registered in the state management table Tb1, the data registered in the state management table Tb1 is checked again with the contents of the address table Tb2 (S10 in FIG. 5), and at least one of the IP address and the device ID is checked. If they match, the duplication is verified (S11 in FIG. 5). If duplication is found here, the information is deleted from the address table Tb1 (S13 in FIG. 5), but in the example of FIG. 6, there is no duplication because it is a reply packet from the newly connected local management device 1, As shown in FIG. 6E, the temporary device ID is rewritten to the original device ID (“3” in the illustrated example) in the area where the IP addresses match. At this time, since the data corresponding to the state management table Tb1 is known, the management index (“3” in the illustrated example) of the address table Tb2 is registered in association with the state management table Tb1.

  Next, a case where the device ID corresponding to the IP address is changed will be exemplified. In the content of the reply packet from the local management apparatus 1 as the transmission source, the IP address is “2001 :: 2” and the device ID is “3” as shown in FIG. In Tb2, as shown in FIG. 7B, the device ID is registered as “2” in association with data whose IP address is “2001 :: 2”, and in the state management table Tb1, as shown in FIG. 7C. In addition, there is data having an IP address “2001 :: 2”, and the IAm data indicates “detachment” of the device 2. “Leaving” is detected by a packet indicating “leaving” transmitted by broadcast at the time of “leaving” if there is no response when the survival confirmation packet is transmitted.

  When an answer packet is received under this condition, some data registered in the address table Tb2 has a matching IP address, and there is a device ID for the IP address, so S3 → S8 → S9 in FIG. The device proceeds to the device registration check process through the Yes route. Further, since there is also a management index corresponding to the IP address in the address table Tb2, the device registration check process proceeds from step S3 to step S4 to S5 in FIG. 4, where the IAm data in the state management table Tb1 is applicable. Since the communication state of the IP address to be performed is “leave”, “Yes” is selected in step S5, and the process proceeds to the registration update process.

  In the registration update process, in step S1 of FIG. 5, there is an IP address that matches the content of the reply packet in the data of the state management table Tb1, and the condition shown in FIG. The process proceeds from S3 to S4, and the contents of a set of data whose communication state is “leave” in the state management table Tb1 as shown in FIG.

  Thereafter, in step S10 of FIG. 5, the IP address and device ID updated in the state management table Tb1 are collated with the IP address and device ID of the address table Tb2 (S10 of FIG. 5), and registered in the state management table Tb1. Data having an IP address that matches the set IP address is updated (steps S11 → S12 in FIG. 5). Then, as shown in FIG. 7E, the device ID of the local management device 1 corresponding to the IP address “2001 :: 2” in the address table Tb2 is changed to “3”.

  The example shown in FIG. 7 is when the device ID is changed, but the same operation is performed when the IP address is changed. By such an operation, it is possible to easily cope with a change in the IP address and device ID of the local management apparatus 1 connected to the upper network Nm.

It is a block diagram which shows embodiment. (A) is a figure which shows the state management table used for the above, (b) is a figure which shows the address table used for the above. It is the whole operation explanatory view same as the above. It is operation | movement explanatory drawing of the device registration check process in the same as the above. It is operation | movement explanatory drawing of the registration update process in the same as the above. It is a figure explaining the operation example same as the above. It is a figure explaining the other operation example same as the above. It is a figure which shows the structural example of an apparatus management communication system. It is a figure which shows the format of the signal used for the same as the above.

Explanation of symbols

1 Local management device (management device)
DESCRIPTION OF SYMBOLS 1a-1c Local management apparatus 2a, 2b Managed apparatus 3 Global management apparatus 11 1st communication part 12 2nd communication part 13 Communication state confirmation part 14 Table management part Lm Transmission path Ls Transmission path Nm Host network (communication network)
Ns Lower level net Tb1 State management table Tb2 Address table

Claims (4)

  A device management system having a communication network to which a plurality of management devices are connected, and a managed device connected to at least one management device separately from the communication network, each management device being hierarchized A communication unit that communicates with another management apparatus using the first protocol and the second protocol, and a survival confirmation packet that inquires about another management apparatus capable of communication up to the second protocol that is a higher layer than the first protocol are transmitted. A communication status confirmation unit that, when receiving a survival confirmation packet, returns a reply packet including a first address used in the first protocol and a second address used in the second protocol to the source of the survival confirmation packet; A state management table in which a second address and a communication state indicating whether communication is possible are registered in association with each other; a first address and a second address; And an address table in which a management index associated with each data in the state management table is registered in association with each other, and a first address and a second address that are communicable in a communication state among the management devices registered in the state management table. A table management unit that extracts and stores the table in an address table, and the communication unit uses the first address and the second address registered in the address table when communicating with another management device. Management communication system.   The communication status confirmation unit causes a survival confirmation packet to be transmitted through the communication unit when a management index corresponding to a first address included in the packet received through the communication unit is unregistered in the address table. The device management communication system according to claim 1.   The table management unit includes the state management table in which at least one of the first address and the second address included in the reply packet received through the communication unit is already registered in the address table and is related by a management index. 3. The device management communication system according to claim 1, wherein the contents of the corresponding data in the state management table and the address table are replaced with the contents of the reply packet only when the communication state of the communication is not possible. .   The table management unit includes the state management table in which at least one of the first address and the second address included in the reply packet received through the communication unit is already registered in the address table and is related by a management index. The device management communication system according to any one of claims 1 to 3, wherein the content of the reply packet is added to the state management table when the communication state of the device is on hold.

Images