Device management system and devices
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- TOSHIBA TEC KK
- Filing Date
- 2025-01-24
- Publication Date
- 2026-08-05
Smart Images
Figure 2026126862000001_ABST
Abstract
Description
Technical Field
[0001] Embodiments of the present invention relate to a device management system and a device.
Background Art
[0002] For example, a service for centrally managing devices such as POS (point-of-sales) devices installed in multiple stores at each store has already been provided. And for such a service, a device management system is also known in which when an event to be managed is detected in each of a large number of devices to be managed, the detection is notified to a management device by communication.
[0003] However, when events to be managed occur simultaneously in a large number of devices, such as an error during an update of a program commonly used in each device, notifications to the management device regarding the detection of the events are concentrated in time, and there has been a risk that the burden on the management device becomes excessive. Under such circumstances, it has been desired to reduce the burden on the management device in a situation where events to be managed occur simultaneously in a large number of devices.
Prior Art Documents
Patent Documents
[0004]
Patent Document 1
Summary of the Invention
Problems to be Solved by the Invention
[0005] The problem to be solved by the present invention is to provide a device management system and a device that can reduce the burden on a management device in a situation where events to be managed occur simultaneously in a large number of devices.
Means for Solving the Problems
[0006] The device management system of this embodiment includes a management device equipped with processing means and a plurality of devices each equipped with detection means, detection notification means, and control means. The detection means detects events that are to be notified to the management device. The detection notification means notifies the management device of detections made by detection means provided on the same device. The control means controls detection notification means provided on the same device to make notifications at a different time than notifications made by detection notification means provided on at least one of the other devices. The processing means performs management processing related to the management of the device equipped with the detection notification means in response to notifications made by the detection notification means. [Brief explanation of the drawing]
[0007] [Figure 1] A block diagram showing the schematic configuration of the device management system according to each embodiment. [Figure 2] A block diagram showing the main circuit configuration of the management server in the first embodiment. [Figure 3] A diagram illustrating an example of the contents of a timing setting table. [Figure 4] A block diagram showing the main circuit configuration of the device in the first embodiment. [Figure 5] A sequence diagram illustrating the rewriting of settings stored in the device's sub-memory unit. [Figure 6] Flowchart of the monitoring process in the first embodiment. [Figure 7] A block diagram showing the main circuit configuration of the management server in the second embodiment. [Figure 8] A block diagram showing the main circuit configuration of the device in the second embodiment. [Figure 9] A diagram illustrating an example of the contents of a level table. [Figure 10] A diagram illustrating an example of the contents of a time limit table. [Figure 11] Flowchart of the monitoring process in the second embodiment. [Figure 12] Block diagram showing the main circuit configuration of the management server in the third embodiment. [Figure 13] Diagram showing an example of the content of the restriction setting table. [Figure 14] Sequence diagram regarding the rewriting of the restriction time table stored in the sub-storage unit of the device. [Figure 15] Block diagram showing the main circuit configuration of the management server in the fourth embodiment. [Figure 16] Block diagram showing the main circuit configuration of the device in the fourth embodiment. [Figure 17] Flowchart of the monitoring process in the fourth embodiment. [Figure 18] Sequence diagram regarding the rejection of a failure notification. [Figure 19] Block diagram showing the main circuit configuration of the management server in the fifth embodiment. [Figure 20] Block diagram showing the main circuit configuration of the device in the fifth embodiment. [Figure 21] Sequence diagram regarding the change of the operation mode of the device. [Figure 22] Flowchart of the monitoring process in the fifth embodiment.
Modes for Carrying Out the Invention
[0008] Hereinafter, several embodiments will be described with reference to the drawings. FIG. 1 is a block diagram showing the schematic configuration of the device management system 1 according to each embodiment. The device management system 1 is configured such that the management server 10 and a plurality of devices 20 can communicate via communication networks 2, 3 and a communication device 4.
[0009] The communication networks 2 and 3 can each be used alone or in appropriate combination, such as the Internet, VPN (virtual private network), LAN, public communication network, mobile communication network, etc. As an example, a VPN is used as the communication network 2. As an example, the Internet is used as the communication network 3. The communication device 4 performs communication processing to enable mutual communication between the communication network 2 and the communication network 3. The communication device 4 has a function of excluding unauthorized access to the management server 10 from the communication network 3 side. As the communication device 4, well-known devices such as a gateway device having a firewall function can be used.
[0010] The management server 10 is an information processing device that executes information processing for managing the device 20 upon receiving a notification from the device 20 accompanying the occurrence of a predetermined event as a management target, and is an example of a management device. That is, the management server 10 provides a remote management service for the device 20 as a web service. The management server 10 is operated by, for example, a service provider that provides a remote management service to the user of the device 20. The management server 10 is realized, for example, as a cloud server that provides the above remote management service as a cloud service in a form called, for example, PaaS (platform as a service) or SaaS (software as a service). Note that, in the present embodiment, the event to be managed by the management server 10 is a predetermined failure that affects the operation of the device 20. However, events different from such failures may be included as management targets. What events are to be managed may be appropriately determined by the specification decision maker of the device management system 1 or the like.
[0011] Device 20 is a device managed by the management server 10. Device 20 can be any type of device. For example, device 20 could be a POS device installed in a store. Device 20 has the function to monitor its own operating status and notify the management server 10 if it detects a failure in the device it is managing.
[0012] [First Embodiment] Figure 2 is a block diagram showing the main circuit configuration of the management server 10 in the first embodiment. The management server 10 includes a CPU (central processing unit) 11, a main storage unit 12, a sub-storage unit 13, a communication unit 14, and a transmission line 15, etc.
[0013] By connecting the CPU 11, the main storage unit 12, and the sub-storage unit 13 via a transmission path 15, a computer is configured to perform information processing for controlling the management server 10. The CPU 11 corresponds to the central part of the computer described above. The CPU 11 performs information processing to control each part in order to realize various functions as a management server 10, in accordance with information processing programs such as the operating system and application programs.
[0014] The main memory unit 12 corresponds to the main memory portion of the computer described above. The main memory unit 12 includes a read-only memory area and a rewritable memory area. The main memory unit 12 stores a portion of the information processing program described above in the read-only memory area. The main memory unit 12 may also store data necessary for the CPU 11 to perform processing to control each part in the read-only memory area or the rewritable memory area. The main memory unit 12 uses the rewritable memory area as a work area for the CPU 11.
[0015] The sub-storage unit 13 corresponds to the auxiliary storage portion of the computer described above. The sub-storage unit 13 can utilize various storage devices, such as EEPROM (electric erasable programmable read-only memory), HDD (hard disk drive), SSD (solid state drive), or other well-known storage devices. The sub-storage unit 13 stores data used by the CPU 11 for various processing tasks and data generated by the processing performed by the CPU 11. The sub-storage unit 13 may also store the information processing programs described above. In this embodiment, the sub-storage unit 13 stores the management program PAA, which is one of the information processing programs. The management program PAA is an application program that describes the procedures for various information processing tasks to realize remote management services. A portion of the storage area of the sub-storage unit 13 is used as an area for storing the timing setting table TAA. The timing setting table TAA will be described later. Although not shown in the diagram, the sub-storage unit 13 also stores event information, operation information, and log information for each of the multiple devices 20. Event information represents the status of device 20, such as errors or completion of operations. Operation information represents the operating status of device 20, such as counter values, sensor values, and operating time measured by device 20. Log information represents logs, such as when errors occur.
[0016] The communication unit 14 performs communication processing for data communication over the communication network 2. The communication unit 14 can use, for example, an existing communication device for a VPN. The transmission line 15 includes an address bus, a data bus, and control signal lines, and transmits data and control signals exchanged between the connected parts.
[0017] The basic hardware for the management server 10 can be, for example, a general-purpose server computer. Generally, the management server 10 is transferred with the management program PAA stored in the sub-storage unit 13. However, the hardware and the management program PAA may be transferred separately, either without the management program PAA stored in the sub-storage unit 13, or with a different version of the same application program stored in the sub-storage unit 13. Furthermore, the management server 10 may be configured by writing the management program PAA to the sub-storage unit 13 in response to an operation by any user. The management program PAA can be transferred by recording it on a removable recording medium such as a magnetic disk, magneto-optical disk, optical disk, or semiconductor memory, or by communication over a network.
[0018] Figure 3 shows an example of the contents of the timing setting table TAA. The timing setting table TAA shown in Figure 3 is an example where the device management system 1 includes 13 devices 20. The timing setting table TAA contains the transmission timing setting values for each of the 13 devices 20, associated with an identifier (hereinafter referred to as device ID) used to identify each device 20. In this embodiment, the unit of the transmission timing setting value is seconds.
[0019] The timing setting table TAA is created as appropriate by any creator, such as the person who determined the specifications for the device management system 1 or the administrator of the management server 10. The timing setting table TAA may be updated thereafter as needed. However, it is preferable for the creator of the timing setting table TAA to assign setting values to each device 20 in a way that minimizes the number of devices 20 with the same setting value. In the example in Figure 3, 12 setting values are used at 5-second intervals, such as "0", "5", and "10", with only "0" being assigned to two devices 20 redundantly. The candidate setting values may be determined as appropriate by the creator, such as 60 values at 1-second intervals, or multiple values with non-uniform time intervals. The timing setting table TAA may also be automatically generated by computer processing.
[0020] Figure 4 is a block diagram showing the main circuit configuration of device 20 in the first embodiment. Device 20 includes a CPU 21, a main memory unit 22, a sub-memory unit 23, an input unit 24, an output unit 25, a communication unit 26, and a transmission line 27, etc. By connecting the CPU 21, main memory unit 22, and sub-memory unit 23 via a transmission line 27, a computer is configured to perform information processing for controlling device 20. The general functions of the CPU 21, main memory unit 22, and sub-memory unit 23 are the same as those of the CPU 11, main memory unit 12, and sub-memory unit 13, so their explanation is omitted here. However, the sub-memory unit 13 stores the monitoring program PBA instead of the management program PAA. Also, the sub-memory unit 13 does not store the timing setting table TAA, but stores the setting value VAA.
[0021] The input unit 24 receives instructions and data in response to operations performed by the operator. Various well-known input devices such as keyboards, mice, and touch panels can be used as the input unit 24. The output unit 25 outputs information for the operator to see. The output unit 25 can be a variety of well-known output devices, such as a display device including an LCD and lamp unit, a sound device with alarm sound and voice message output capabilities, or a printer.
[0022] The communication unit 26 performs communication processing for data communication via the communication network 3. The communication unit 26 also performs communication processing for exchanging data with peripheral devices (not shown) attached to the device 20, such as a scanner, printer, and change dispenser. The communication unit 26 includes, for example, an existing communication device for the internet and an existing interface device compliant with the USB (universal serial bus) standard. The transmission line 27 includes an address bus, a data bus, and control signal lines, and transmits data and control signals exchanged between the connected parts.
[0023] The basic hardware of device 20 can be the hardware of various devices, such as existing POS terminals included in a POS system. Generally, device 20 is transferred with the monitoring program PBA stored in the sub-storage unit 23. However, the hardware and the monitoring program PBA may be transferred separately, either without the monitoring program PBA stored in the sub-storage unit 23, or with a different version of the same application program stored in the sub-storage unit 23. Furthermore, device 20 may be configured by writing the monitoring program PBA to the sub-storage unit 23 in response to an operation by any worker. The monitoring program PBA can be transferred by recording it on a removable recording medium such as a magnetic disk, magneto-optical disk, optical disk, or semiconductor memory, or by communication over a network.
[0024] Figure 4 shows one example configuration of the multiple devices 20 included in the device management system 1. The multiple devices 20 included in the device management system 1 may include configurations different from those shown in Figure 4. For example, the multiple devices 20 may include some that do not have at least one of the input unit 24 and the output unit 25.
[0025] Next, the operation of the device management system 1 of the first embodiment configured as described above will be explained. Note that the content of the processes described below is an example, and it is possible to change the order of some processes, omit some processes, or add other processes as appropriate. For example, in the following explanation, the explanation of some processes has been omitted in order to explain the characteristic operation of this embodiment in an easy-to-understand manner. For example, after transitioning from one processing state to another, the system may return to the processing state before the transition in response to instructions from the operator, but such processes have been omitted from the description. Or, for example, if some error occurs, processing to deal with that error may be performed, but such processes have been omitted from the description.
[0026] (Overwriting the setting value) Figure 5 is a sequence diagram relating to the rewriting of the setting value VAA stored in the sub-storage unit 23 of device 20. When a new device management system 1 is built, when a device 20 is added, or when settings are reviewed, the management server 10 either writes the timing setting table TAA to the sub-storage unit 13 or updates the timing setting table TAA already stored in the sub-storage unit 13 in response to an operation by the operator. The operator then instructs the management server 10 to change the settings of the device 20. This instruction to change settings may apply to all devices 20 or to only some of the devices 20. Upon receiving this instruction, the CPU 11 in the management server 10 proceeds to ACT101 in Figure 5 as part of the information processing based on the management program PAA.
[0027] It is assumed that the above instructions to the management server 10 by the operator, or the various instructions described later, will be made via the communication network 2 from any information terminal not shown in Figure 1. Alternatively, instructions to the management server 10 by the operator may be made via an input device built into or externally attached to the management server 10.
[0028] As ACT101, CPU11 reads the setting value described in the timing setting table TAA, associated with the device ID of the device 20 that is to be changed. As ACT102, CPU11 requests a change in the setting value from the device 20 that is subject to modification. For example, CPU11 generates a predetermined request data for requesting a change in the setting value, including the setting value read in ACT101, and sends this to the device 20 via the communication network 2. When this request data is transmitted to the destination device 20 via the communication network 2, communication device 4, and communication network 3, it is received by the communication unit 26 provided in the device 20. In response, the CPU21 in the device 20 proceeds to ACT201 in the information processing based on the monitoring program PBA.
[0029] As ACT201, CPU21 writes the setting value included in the request data to sub-storage unit23 as setting value VAA. If setting value VAA is already stored, CPU21 overwrites it with the setting value included in the request data. In this way, the sub-storage units 23 of the multiple devices 20 each store the setting value VAA described in the timing setting table TAA for each device 20.
[0030] (Responding to problems) When the CPU 21 on device 20 is in an operating state under the management of the device management system 1, it executes monitoring processing based on the monitoring program PBA. Figure 6 is a flowchart of the monitoring process in the first embodiment.
[0031] As ACT211, CPU21 performs fault detection processing. Fault detection processing is a process to confirm whether a managed fault has occurred in the operation of device 20 itself or the operation of peripheral devices. Thus, by having CPU21 execute information processing based on the monitoring program PBA, the computer with CPU21 as its central component functions as a detection means.
[0032] As ACT212, CPU21 checks whether a fault has been detected by the fault detection process described above. If no fault has been detected, CPU21 determines NO and returns to ACT211. Note that if CPU21 determines NO in ACT212 and returns to ACT211, it may wait a while before executing ACT211 again. Also, if there are multiple faults to be detected in the fault detection process, it may not detect all faults each time ACT211 is executed, but rather selectively detect faults according to a predetermined schedule, for example. If CPU21 detects any fault in ACT211, it determines YES in ACT212 and proceeds to ACT213.
[0033] As ACT213, CPU21 retrieves the setting value VAA stored in sub-storage unit23. As ACT214, CPU21 checks whether it is the right time to send for its device 20. For example, CPU21 checks if the current time in seconds matches the setting value VAA obtained in ACT213. If they do not match, CPU21 determines that it is not the right time to send and proceeds to ACT215.
[0034] As ACT215, CPU21 waits for a predetermined waiting time. If the set value VAA is set to seconds, and ACT214 checks that the current time in seconds matches the set value VAA, then the waiting time is expected to be 1 second or less. However, it is preferable to set the waiting time to 500 milliseconds to ensure that the current time in seconds matches the set value VAA. Once the waiting time has elapsed, CPU21 returns to ACT214.
[0035] For example, if the CPU 21 finds that the current time in seconds matches the set value VAA, it determines that it is time to send a message and verifies YES in ACT 214, then proceeds to ACT 216. In this way, the CPU 21 performs information processing based on the monitoring program PBA, and the computer with the CPU 21 as its central component functions as a control system.
[0036] As ACT216, CPU21 notifies the management server 10 of the failure. For example, CPU21 generates predetermined notification data for failure notification, including an identifier (hereinafter referred to as event ID) to identify what kind of failure it is that was detected by ACT211, and sends this to the management server 10 via the communication network 3. Thus, by having CPU21 perform information processing based on the monitoring program PBA, the computer with xCPU21 as its central component functions as a detection and notification means.
[0037] CPU21 then returns to ACT211 to prepare for the occurrence of another failure. Depending on the failure that has occurred, CPU21 may take measures to stop the normal operation of device 20 through control processing separate from the monitoring process. In this case, CPU21 may also stop the monitoring process.
[0038] When the above notification data is transmitted to the management server 10 via communication network 3, communication device 4, and communication network 2, the communication unit 14 installed in the management server 10 receives it. In response, the CPU 11 in the management server 10 executes management processing corresponding to the event ID included in the notification data. The management processing may be the same as that performed in existing systems of the same type. The specific processing to be performed as management processing may be determined as appropriate by the person who determined the specifications of the device management system 1, and such explanation is omitted here. Thus, by the CPU 11 executing information processing based on the management program PAA, the computer with the CPU 11 as its central component functions as a processing means.
[0039] Thus, even if a failure occurs in all devices 20 at 0:00:00 due to, for example, a malfunction in the control program that controls the operation of the devices, each device 20 will issue a failure notification at a different time, such as device 20 with device ID "A0002" at 0:00:05, device 20 with device ID "A0003" at 0:00:10, and device 20 with device ID "A0004" at 0:00:15. At 0:01:00, device 20 with device ID "A0001" and device 20 with device ID "A0013" will issue failure notifications simultaneously. In other words, the setting value VAA is an example of setting information where at least one device 20 has a different notification timing. The sub-storage unit 23 corresponds to a storage means that stores this setting value VAA as setting information. In this way, even if a large-scale failure causes a situation where failures are detected simultaneously on a large number of devices 20, the timing of failure notifications from these numerous devices 20 can be distributed, reducing the burden on the management server 10.
[0040] [Second Embodiment] Figure 7 is a block diagram showing the main circuit configuration of the management server 10 in the second embodiment. Figure 8 is a block diagram showing the main circuit configuration of device 20 in the second embodiment. In Figures 7 and 8, the same reference numerals are used for elements that are the same as those shown in Figures 2 and 4, and their detailed explanations are omitted.
[0041] As shown in Figures 7 and 8, the hardware configuration of the management server 10 and device 20 in the second embodiment may be the same as in the first embodiment. However, in the management server 10 of the second embodiment, the sub-storage unit 13 stores the management program PAB instead of the management program PAA, and does not store the timing setting table TAA. Also, in the device 20 of the second embodiment, the sub-storage unit 23 stores the monitoring program PBB instead of the monitoring program PBA, and does not store the setting value VAA. Furthermore, in the device 20 of the second embodiment, a portion of the storage area of the sub-storage unit 23 is used as an area for storing the level table TAB and the time limit table TAC.
[0042] Figure 9 shows an example of the contents of the level table TAB. The level table TAB shown in Figure 9 is an example of classifying the failures managed by the device management system 1 into 12 types. The level table TAB describes a level representing the urgency of each of these 12 types of failures, associated with an identifier (hereinafter referred to as an event ID) used to identify each of these failures. In this embodiment, there are three levels: "Urgent," "Warning," and "Information," with the order of urgency being "Urgent" > "Warning" > "Information."
[0043] Figure 10 shows an example of the contents of the time limit table TAC. In the time limit table TAC shown in Figure 10, the notification time limits for each of the fault levels, "Emergency," "Warning," and "Information," are described as "5 seconds," "10 seconds," and "15 seconds," respectively.
[0044] The level table TAB and the time limit table TAC are created as appropriate by any creator, such as the person who determined the specifications for the device management system 1, and are written to the sub-storage units 13 of all devices 20 when the device management system 1 is newly constructed. The level table TAB and the time limit table TAC may be updated as appropriate when devices 20 are added or their settings are revised. However, the time limit table TAC should describe shorter time limits for levels of higher urgency.
[0045] Next, the operation of the device management system 1 of the second embodiment configured as described above will be explained. Note that the content of the processes described below is an example, and it is possible to change the order of some processes, omit some processes, or add other processes as appropriate. For example, in the following explanation, the explanation of some processes has been omitted in order to explain the characteristic operation of this embodiment in an easy-to-understand manner. For example, after transitioning from one processing state to another, the system may return to the processing state before the transition in response to instructions from the operator, but such processes have been omitted from the description. Or, for example, if some error occurs, processing to deal with that error may be performed, but such processes have been omitted from the description.
[0046] In the second embodiment, the setting value VAA in the first embodiment is not used, and no process is performed to rewrite it. When the CPU 21 on device 20 is in an operating state under the management of the device management system 1, it executes monitoring processing based on the monitoring program PBB.
[0047] Figure 11 is a flowchart of the monitoring process in the second embodiment. In Figure 11, the same reference numerals are used for the same processes shown in Figure 6, and their detailed explanations are omitted. CPU21 performs ACT211 and ACT212 in the same manner as in the first embodiment. If CPU21 determines YES in ACT212, it proceeds to ACT221.
[0048] As ACT221, CPU21 determines the level of the detected fault. For example, CPU21 retrieves the level described in the level table TAB for the event ID of the fault detected by ACT211. As ACT222, CPU21 determines the waiting time so as not to exceed the time limit corresponding to the level determined in ACT221. For example, CPU21 obtains the time limit described in the time limit table TAC for the level determined in ACT221. Then, CPU21 randomly determines a number of seconds within the range that does not exceed the obtained time limit, and sets that number of seconds as the waiting time. For example, if CPU21 detects a fault with event ID "E0003" in ACT211, it will randomly determine the waiting time as a number of seconds not exceeding "10 seconds".
[0049] As ACT223, CPU21 waits for the transmission timing. Then, for example, if the elapsed time from the predetermined start timing reaches the waiting time determined in ACT222, CPU21 determines YES in ACT223 and proceeds to ACT216. CPU21 then executes ACT216 in the same manner as in the first embodiment and notifies the management server 10 of the occurrence of the failure. The operation of the management server 10 upon receiving this notification is the same as in the first embodiment. Note that the start timing here is assumed to be, for example, the timing when the failure is detected in ACT211. However, the start timing here may be appropriately determined by the person who determined the specifications of the device management system 1, etc., so as to allow for an interval corresponding to the waiting time between the occurrence of the failure and the failure notification.
[0050] Thus, even if all devices 20 fail simultaneously due to, for example, a malfunction in the control program that controls the operation of the devices, each device 20 will send a failure notification after a randomly determined waiting time has elapsed. Therefore, even if a large-scale failure causes a large number of devices 20 to fail simultaneously, the timing of failure notifications from these numerous devices 20 can be distributed, reducing the burden on the management server 10. Furthermore, by changing the waiting time limit according to the urgency of the failure that occurs, notifications for less urgent failures can be sent over a wider time range and at more distributed timings, further reducing the burden on the management server 10.
[0051] [Third Embodiment] Figure 12 is a block diagram showing the main circuit configuration of the management server 10 in the third embodiment. In Figure 12, elements identical to those shown in Figure 2 are denoted by the same reference numerals, and their detailed explanations are omitted.
[0052] As shown in Figure 12, the hardware configuration of the management server 10 in the third embodiment may be the same as in the first embodiment. However, in the management server 10 of the third embodiment, the sub-storage unit 13 stores the management program PAC instead of the management program PAA, and does not store the timing setting table TAA. Furthermore, in the management server 10 of the third embodiment, a portion of the storage area of the sub-storage unit 13 is used as an area for storing the limit setting table TAD. The configuration of device 20 in the third embodiment is substantially the same as that of device 20 in the second embodiment, so it is omitted from the illustration. However, in the third embodiment, the monitoring program stored in the sub-storage unit 23 is different from the monitoring program PBB.
[0053] Figure 13 shows an example of the contents of the restriction setting table TAD. The limit setting table TAD shown in Figure 13 is an example where the device management system 1 includes 13 devices 20. The timing setting table TAA then describes the time limits for each device 20 identified by its device ID, categorized by the level of failure.
[0054] The restriction setting table TAD is created as appropriate by any creator, such as the specification setter for the device management system 1 or the administrator of the management server 10. The restriction setting table TAD may be updated thereafter as needed. However, for each device 20, the restriction setting table TAD should describe shorter restriction times for higher levels of urgency. The restriction setting table TAD may also be automatically generated by computer processing.
[0055] Next, the operation of the device management system 1 of the third embodiment configured as described above will be explained. Note that the content of the processes described below is an example, and it is possible to change the order of some processes, omit some processes, or add other processes as appropriate. For example, in the following explanation, the explanation of some processes has been omitted in order to explain the characteristic operation of this embodiment in an easy-to-understand manner. For example, after transitioning from one processing state to another, the system may return to the processing state before the transition in response to instructions from the operator, but such processes have been omitted from the description. Or, for example, if some error occurs, processing to deal with that error may be performed, but such processes have been omitted from the description.
[0056] Figure 14 is a sequence diagram relating to the rewriting of the time limit table TAC stored in the sub-storage unit 23 of device 20. When a new device management system 1 is built, when a device 20 is added, or when settings are reviewed, the management server 10 either writes the restriction setting table TAD to the sub-storage unit 13 or updates the restriction setting table TAD already stored in the sub-storage unit 13 in response to an operation by the operator. The operator then instructs the management server 10 to change the settings of the device 20. This instruction to change settings may apply to all devices 20 or to only some of the devices 20. Upon receiving this instruction, the CPU 11 in the management server 10 proceeds to ACT111 in Figure 14 as part of the information processing based on the management program PAC.
[0057] As ACT111, CPU11 reads all the time limits described in the limit setting table TAD, associated with the device ID of the device 20 that is subject to modification. As ACT112, CPU11 requests a change to the time limit table TAC from the device 20 that is subject to modification. For example, CPU11 generates request data, predetermined to include the time limit read in ACT111, for the device 20 in question, and sends this to the communication network 2. When this request data is transmitted to the destination device 20 via communication network 2, communication device 4, and communication network 3, it is received by the communication unit 26 provided in the device 20. In response, the CPU21 in the device 20 proceeds to ACT231 in the information processing based on the monitoring program.
[0058] As ACT231, CPU21 updates the time limit table TAC stored in sub-storage unit23 to represent the time limit included in the request data. The time limits stored in the sub-storage units 23 of the multiple devices 20 in this manner are the time limits set for each device 20 in the time limit setting table TAD.
[0059] Furthermore, the management program PAC and monitoring program in the third embodiment differ from the management program PAB and monitoring program PBB in the second embodiment in that they add processing for updating the time limit table TAC. The other processing by CPU 11 and CPU 21 based on the management program PAC and monitoring program in the third embodiment is the same as in the second embodiment.
[0060] Thus, similar to the second embodiment, the burden on the management server 10 can be further reduced. Furthermore, by setting different time limits for each device 20, it is possible to further distribute the timing of notifications while ensuring that failure notifications for more important devices 20 are sent in a short period of time.
[0061] [Fourth Embodiment] Figure 15 is a block diagram showing the main circuit configuration of the management server 10 in the fourth embodiment. Figure 16 is a block diagram showing the main circuit configuration of device 20 in the fourth embodiment. In Figures 15 and 16, the same reference numerals are used for elements that are the same as those shown in Figures 2, 4, and 12, and their detailed explanations are omitted.
[0062] As shown in Figures 15 and 16, the hardware configuration of the management server 10 and device 20 in the fourth embodiment may be the same as in the second embodiment. However, in the management server 10 of the fourth embodiment, the sub-storage unit 13 stores the management program PAD instead of the management program PAB. Also, in the device 20 of the fourth embodiment, the sub-storage unit 23 stores the monitoring program PBC instead of the monitoring program PBB.
[0063] Next, the operation of the device management system 1 of the fourth embodiment configured as described above will be explained. Note that the content of the processes described below is an example, and it is possible to change the order of some processes, omit some processes, or add other processes as appropriate. For example, in the following explanation, the explanation of some processes has been omitted in order to explain the characteristic operation of this embodiment in an easy-to-understand manner. For example, after transitioning from one processing state to another, the system may return to the processing state before the transition in response to instructions from the operator, but such processes have been omitted from the description. Or, for example, if some error occurs, processing to deal with that error may be performed, but such processes have been omitted from the description.
[0064] When the CPU 21 on device 20 is in an operating state under the management of the device management system 1, it executes monitoring processing based on the monitoring program PBC. Figure 17 is a flowchart of the monitoring process in the fourth embodiment. In Figure 17, the same reference numerals are used for the same processes shown in Figure 6 or Figure 11, and their detailed explanations are omitted.
[0065] CPU21 performs ACT211 and ACT212 in the same manner as in the first embodiment. If CPU21 determines YES in ACT212, it proceeds to ACT216 and performs ACT216 in the same manner as in the first embodiment. In other words, in the fourth embodiment, when device 20 detects a fault, it immediately issues a fault notification.
[0066] The management server 10 can receive failure notifications from a large number of devices 20 simultaneously. However, the CPU 11 has a limit to the number of information processing operations it can perform in parallel for handling failure notifications. Therefore, the CPU 11 performs the following processing to reject failure notifications that exceed its processing capacity.
[0067] Figure 18 is a sequence diagram related to the rejection of fault notifications. When CPU 11 receives a fault notification from device 20, it proceeds to ACT121 in Figure 18 through information processing based on the management program PAD. As ACT121, CPU11 checks whether a predetermined rejection condition is met. The rejection condition is expected to be, for example, "the number of information processing executions for taking action in response to a failure notification exceeds a predetermined limit." The rejection condition may be determined as appropriate by the person who determined the specifications of the device management system 1.
[0068] If the rejection condition is not met, CPU 11 performs the same processing as in the first embodiment in response to receiving the failure notification. However, if the rejection condition is met, CPU 11 proceeds to ACT 122. As ACT122, CPU11 sends a rejection notification to device 20, the source of the failure notification. For example, CPU11 sends predetermined notification data for the rejection notification to the device 20 via the communication network 2. Thus, by having CPU11 perform information processing based on the management program PAD, the computer with CPU11 as its central component functions as a rejection notification means.
[0069] On device 20, CPU 21 issues a fault notification at ACT216 in Figure 17, and then proceeds to ACT241. As ACT241, CPU21 checks whether a rejection notification has been sent. Then, CPU21 determines that the notification data sent from management server 10 as described above has been transmitted to device 20 via communication network 2, communication device 4 and communication network 3, and received by communication unit 26, and proceeds to ACT221. After performing ACT221 and ACT222 in the same manner as in the second embodiment, CPU21 proceeds to ACT242.
[0070] As ACT242, CPU21 waits for the transmission timing. Then, for example, if the elapsed time from the predetermined start timing reaches the waiting time determined in ACT222, CPU21 determines YES in ACT242 and proceeds to ACT243. The start timing here is expected to be, for example, the timing when the rejection notification is confirmed in ACT241. However, the start timing here may be appropriately determined by the person who determined the specifications of the device management system 1, etc., so as to allow for an interval corresponding to the waiting time between the rejection notification being made and the re-notification described later.
[0071] As ACT243, CPU21 re-notifies the management server 10 of the failure. For example, CPU21 generates predetermined notification data for re-notification, including the event ID of the failure detected by ACT211, and sends this to the management server 10 via the communication network 3. Thus, by having CPU21 perform information processing based on the monitoring program PBC, the computer with CPU21 as its central component functions as a means of re-notification.
[0072] CPU21 then returns to ACT211 to prepare for the occurrence of another failure. CPU21 may also simply resend the notification data sent by ACT216. The management server 10's response to this resend is the same as the response to receiving the failure notification in ACT216.
[0073] Thus, each device 20 initially issues a failure notification upon detecting a failure. When the management server 10 is able to process the failure in response to the failure notification, it can quickly do so. Furthermore, even if a large number of failure notifications exceed the management server 10's parallel processing capacity due to, for example, a malfunction in the control program that controls the operation of the devices 20, some of these failure notifications will be rejected. Devices 20 whose failure notifications have been rejected will then re-notify the management server 10 of the failure after a randomly determined waiting period has elapsed. Therefore, even in situations where a large-scale failure causes a large number of devices 20 to detect failures simultaneously, the timing of the failure notifications from these numerous devices 20 can be distributed, reducing the burden on the management server 10.
[0074] [Fifth Embodiment] Figure 19 is a block diagram showing the main circuit configuration of the management server 10 in the fifth embodiment. Figure 20 is a block diagram showing the main circuit configuration of device 20 in the fifth embodiment. In Figures 19 and 20, the same reference numerals are used for elements that are the same as those shown in Figures 2, 4, and 12, and their detailed explanations are omitted.
[0075] As shown in Figures 19 and 20, the hardware configuration of the management server 10 and device 20 in the fifth embodiment may be the same as in the fourth embodiment. However, in the management server 10 of the fifth embodiment, the sub-storage unit 13 stores the management program PAE instead of the management program PAD. Also, in the device 20 of the fifth embodiment, the sub-storage unit 23 stores the monitoring program PBD instead of the monitoring program PBC.
[0076] Next, the operation of the device management system 1 of the fifth embodiment configured as described above will be explained. Note that the content of the processes described below is an example, and it is possible to change the order of some processes, omit some processes, or add other processes as appropriate. For example, in the following explanation, the explanation of some processes has been omitted in order to explain the characteristic operation of this embodiment in an easy-to-understand manner. For example, after transitioning from one processing state to another, the system may return to the processing state before the transition in response to instructions from the operator, but such processes have been omitted from the description. Or, for example, if some error occurs, processing to deal with that error may be performed, but such processes have been omitted from the description.
[0077] Figure 21 is a sequence diagram relating to the change in the operating mode of device 20. If the administrator of the management server 10 updates the control program of the devices 20, and there is a risk of errors occurring simultaneously in a large number of devices 20, the administrator will instruct the management server 10 to stop retransmission. This instruction to stop retransmission may be given to all devices 20 or to only some of all devices 20. Upon receiving this instruction, the CPU 11 in the management server 10 proceeds to ACT131 in Figure 21 as part of the information processing based on the management program PAE.
[0078] As ACT131, CPU11 requests the device 20 that is to be stopped to stop retransmission. For example, CPU11 sends predefined request data for requesting retransmission stop to the device 20 and onto the communication network 2. Thus, by having CPU11 perform information processing based on the management program PAE, the computer with CPU11 as its central component functions as a request mechanism. When the above request data is transmitted to the destination device 20 via communication network 2, communication device 4, and communication network 3, it is received by the communication unit 26 installed in the device 20. In response, the CPU 21 in the device 20 proceeds to ACT 251 in the information processing based on the monitoring program PBD. As ACT251, CPU21 sets the operating mode of the device 20 in which it is installed to retransmission stop mode.
[0079] The administrator of the management server 10, at an appropriate time, instructs the management server 10 to start retransmission. This instruction to stop retransmission may be applied to all devices 20 that are set to retransmission stop mode, or to some of the devices 20 that are set to retransmission stop mode. Upon receiving this instruction, the CPU 11 on the management server 10 proceeds to ACT 132 in Figure 21.
[0080] As ACT132, CPU11 requests the device 20 that is being stopped to restart transmission. For example, CPU11 sends predefined request data to the communication network 2 addressed to the device 20 to request the restart of transmission. When this request data is transmitted to the destination device 20 via communication network 2, communication device 4 and communication network 3, it is received by the communication unit 26 installed in the device 20. In response, CPU21 in the device 20 proceeds to ACT252.
[0081] As ACT252, CPU21 cancels the retransmission stop mode, which was set as described above as the operating mode of the device 20 on which CPU21 is installed. Thus, device 20 enters retransmission stop mode from the time it receives a retransmission stop request until it receives a retransmission start request.
[0082] On the other hand, when the CPU 21 in device 20 is in an operating state under the management of the device management system 1, it executes monitoring processing based on the monitoring program PBD. Figure 22 is a flowchart of the monitoring process in the fifth embodiment. In Figure 22, the same reference numerals are used for the same processes shown in Figures 6, 11, or 17, and their detailed explanations are omitted.
[0083] As shown in Figure 22, the monitoring process in the fifth embodiment differs from the fourth embodiment in that, after determining the waiting time as ACT222, ACT261 is performed before proceeding to ACT242. As ACT261, CPU21 checks whether the retransmission stop mode is set. If the retransmission stop mode is set as described above, it waits for the retransmission stop mode to be released. Then, if the retransmission stop mode is released as described above, CPU21 determines NO and performs ACT242 and ACT243 in the same way as in the fourth embodiment. However, as ACT243 in the fifth embodiment, CPU21 uses the timing at which it determined NO in ACT261 as the start timing.
[0084] Thus, according to the fifth embodiment, in situations where there is a risk of failure occurring simultaneously on a large number of devices 20, re-notification can be temporarily stopped, preventing an increase in the burden on the management server 10 due to a concentration of re-notifications.
[0085] This embodiment can be modified in various ways as follows: The processing on the management server 10 may be implemented through distributed processing on multiple information processing devices.
[0086] Each of the functions realized by CPUs 11 and 21 through information processing can also be partially or entirely realized by hardware that performs non-program-based information processing, such as logic circuits. Furthermore, each of the above functions can also be realized by combining the above-mentioned hardware, such as logic circuits, with software control.
[0087] While several embodiments of the present invention have been described, these embodiments are presented as examples only and are not intended to limit the scope of the invention. These novel embodiments can be carried out in a variety of other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their variations are included in the scope and spirit of the invention, as well as in the claims of the invention and its equivalents. [Explanation of Symbols]
[0088] 1...Device management system, 2,3...Communication network, 4...Communication device, 10...Management server, 20...Device, 11,21...CPU, 12,22...Main memory unit, 13,23...Sub memory unit, 14,26...Communication unit, 15,27...Transmission path, 24...Input unit, 25...Output unit.
Claims
1. Includes a management device and multiple devices, Each of the multiple devices is, A detection means for detecting events that are subject to notification to the management device, A detection notification means that notifies the management device of a detection by the detection means provided in the same device, Control means for controlling the detection notification means provided in the same device so as to provide a notification at a different time than a notification provided by the detection notification means provided in at least one of the other devices, It is equipped with, The aforementioned control device is Processing means that performs management processing related to the management of the device equipped with the detection notification means in response to a notification from the detection notification means. Equipped with, Device management system.
2. Each of the multiple devices is, A storage means for storing notification timing setting information that is predetermined to be different from the notification timing provided by the detection notification means in at least one of the other devices, Furthermore, The control means controls the detection notification means provided in the same device to provide notifications at a notification timing corresponding to the setting information stored in the storage means provided in the same device. The device management system according to claim 1.
3. The control means randomly determines a waiting time and controls the detection notification means provided in the same device so that the interval from detection by the detection means provided in the same device to notification by the detection notification means provided in the same device is corresponding to the waiting time. The device management system according to claim 1.
4. The control means controls the detection notification means which determines the waiting time so as not to exceed a predetermined time limit. The device management system according to claim 3.
5. The aforementioned detection means detects multiple events, The control means applies a predetermined time limit to the control of the detection notification means in response to an event detected by the detection means provided in the same device. The device management system according to claim 4.
6. The processing means is capable of performing in parallel management processing for a limited number of devices that is less than the total number of devices. The aforementioned control device further, When the processing means is processing the management process for the limit number in parallel, a rejection notification means notifies the device equipped with the detection notification means that it will refuse to execute the management process in response to a notification from the detection notification means. Furthermore, The aforementioned device further, A re-notification means that, in response to a notification by the rejection notification means, causes the detection notification means provided in the same device to send another notification. Furthermore, A device management system according to any one of claims 1 to 5.
7. The aforementioned control device further, The system further comprises a stop request means for requesting the cessation of retransmission to at least some of the devices to be stopped, which are designated as a subset of the plurality of devices, The aforementioned re-notification means shall not allow the device equipped with the re-notification means to send another notification after a request has been made by the stop request means. The device management system according to claim 6.
8. The aforementioned control device further, The system further comprises a start request means for requesting the start of retransmission to a target device, which is defined as at least some of the multiple devices, The aforementioned re-notification means causes the device equipped with the re-notification means to issue a second notification after the request by the start request means has been received. The device management system according to claim 7.
9. A device used in a device management system which includes a management device and multiple devices, A detection means for detecting events that are subject to notification to the management device, A detection notification means for notifying the management device of the detection by the detection means, Control means for controlling the detection notification means so that the notification by the detection notification means is made at a different timing than the notification by another device to the management device, A device equipped with [a certain feature].