Electronic system and error management method thereof

By using monitoring and management devices in electronic systems, real-time analysis of screen image data and automatic processing of operating system errors, the resource waste and delay problems of uncontrollable error management in the prior art are solved, and the efficiency and accuracy of error handling are improved.

CN119311536APending Publication Date: 2025-01-14SAMSUNG ELECTRONICS CO LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202410319710.4
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2023-07-13
Filing Date
2024-03-20
Publication Date
2025-01-14

AI Technical Summary

Technical Problem

The prior art is difficult to effectively manage and automatically resolve uncontrollable errors in electronic systems, especially when the operating system crashes, which require manual access to perform subsequent actions, resulting in waste of resources and delays.

Method used

An electronic system is designed to monitor errors in the operating system in real time through the communication network of the monitored device and the management device, determine the error type based on screen image data analysis, and automatically perform corresponding subsequent actions to reduce manual intervention and time waste.

Benefits of technology

It realizes rapid and automatic processing of uncontrollable errors, reduces the waste of manpower and time resources, improves the accuracy and efficiency of error management, and reduces the calculation amount and power consumption.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119311536A_ABST
    Figure CN119311536A_ABST
Patent Text Reader

Abstract

An electronic system and a method of managing errors are provided. An electronic system includes a monitored device and a management device. The monitored device operates according to an operating system and generates a display image. The management device is connected to the monitored device through a communication network. A management device periodically receives screen image data corresponding to a display image from a monitored device, and determines whether an error that makes an operating system of the monitored device inoperable has occurred in the operating system of the monitored device on the basis of a network connection state with the monitored device. A type of the error is determined based on the error determination factor and a result of analysis of the screen image data, and a request indicating a subsequent action to be taken to solve the error is transmitted to the monitored device, the subsequent action corresponding to the type of the error.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority from Korean Patent Application No. 10-2023-0090907 filed on July 13, 2023 in the Korean Intellectual Property Office (KIPO), the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] Example embodiments relate generally to semiconductor integrated circuits, and more particularly, to electronic systems and methods of managing errors of electronic systems. Background Art

[0004] Most electronic devices or systems run operating system software, and when an unexpected serious error occurs, the operating system (OS) may not respond to commands or requests from input devices such as keyboards, mice, etc. or from remote devices via a network. In this case, a person must personally visit the place where the electronic device is located and perform analysis or recovery.

[0005] On Windows TM In the case of a blue screen of death (BSOD) in Windows XP, the operating system software provides an option to perform a memory dump for analyzing the operating system software and restarting the operating system software, but in other cases, subsequent actions such as analysis or recovery can only be performed by personally visiting the physical location of the failed electronic device running the operating system software. In addition, when an operating system error occurs due to a peripheral device such as a storage device, the operating system software is automatically restarted by Windows XP. TM The provided memory dump and operating system restart are not useful because the error condition and analysis time are critical. Summary of the invention

[0006] One aspect is to provide an electronic system capable of effectively managing uncontrollable errors in an operating system and a method for managing errors of the electronic system.

[0007] According to an aspect of one or more example embodiments, an electronic system is provided, comprising: a monitored device, configured to operate according to an operating system and generate a display image; and a management device, connected to the monitored device via a communication network and configured to periodically receive screen image data corresponding to the display image from the monitored device; determining whether an error occurs in the operating system of the monitored device that renders the operating system of the monitored device inoperable based on a network connection status with the monitored device; determining a type of error based on a plurality of error determination factors and an analysis result of the screen image data; and transmitting to the monitored device a request indicating a subsequent action to be taken to resolve the error, the subsequent action corresponding to the type of error.

[0008] According to another aspect of one or more example embodiments, an electronic system is provided, comprising: a plurality of monitored devices, each of the monitored devices being configured to operate according to an operating system, the plurality of monitored devices being configured to respectively generate a plurality of display images; and a management device, which is connected to the plurality of monitored devices via a communication network and is configured to periodically receive a plurality of screen image data corresponding to the plurality of display images from the plurality of monitored devices; determining, based on a network connection status with the plurality of monitored devices, whether an error occurs in an operating system of one of the plurality of monitored devices that renders the operating system of one of the plurality of monitored devices inoperable; determining a type of the error based on a plurality of error determination factors and an analysis result of a plurality of screen image data of one of the plurality of monitored devices; and transmitting, to one of the plurality of monitored devices, a request indicating a subsequent action to be taken to resolve the error, the subsequent action corresponding to the type of the error.

[0009] According to another aspect of one or more example embodiments, there is provided a method for managing errors of a monitored device, the monitored device operating according to an operating system and configured to generate a display image, the method being performed by a management device connected to the monitored device via a communication network, the method comprising: periodically receiving screen image data corresponding to the display image from the monitored device; determining, based on a network connection status with the monitored device, whether an error has occurred in the operating system of the monitored device that renders the operating system of the monitored device inoperable; determining a type of error based on a plurality of error determination factors and analysis results of the screen image data; and indicating to the monitored device a request for subsequent actions to be taken to resolve the error, the subsequent actions corresponding to the type of error. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Various example embodiments will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings, in which:

[0011] Figure 1 is a diagram illustrating an electronic system according to an example embodiment;

[0012] Figure 2 is a flow chart illustrating a method of managing errors of an electronic system according to an example embodiment;

[0013] Figure 3 is a flowchart illustrating a process of performing a method of managing errors of an electronic system according to an example embodiment;

[0014] Figure 4 is a diagram illustrating error determination factors and error types according to an example embodiment;

[0015] Figure 5 is a flow chart illustrating determining an error according to an example embodiment;

[0016] Figures 6 to 10 is a diagram illustrating an example of screen image data in a method of managing errors of an electronic system according to an example embodiment;

[0017] Fig.11 is a flow chart illustrating a method of managing errors of an electronic system according to an example embodiment;

[0018] Fig.12 is a flow chart illustrating determining an error according to an example embodiment;

[0019] Fig.13 is a flow chart illustrating a method of managing errors of an electronic system according to an example embodiment;

[0020] Fig.14 is a block diagram illustrating a monitored device included in an electronic system according to an example embodiment;

[0021] Fig.15 is a diagram showing a method of including Fig.14 A block diagram of an example of a storage controller in a monitored device;

[0022] Fig.16 It is shown that the Fig.14 A block diagram of an example of a non-volatile memory device in a monitored device;

[0023] Fig.17 is a diagram showing a method of including Fig.16 A block diagram of a memory cell array in a non-volatile memory device;

[0024] Fig.18 is a diagram showing a method of including Fig.17 A circuit diagram of an equivalent circuit of a memory block in a memory cell array;

[0025] Fig.19 is a diagram showing a method according to an example embodiment Fig.14 A diagram of an example operation of a monitored device;

[0026] Fig. 20 is a block diagram illustrating an example of an error management module included in a management device of an electronic system according to an example embodiment;

[0027] Fig.21 It is shown that the Fig. 20 A block diagram of an example of an image converter in an error management module;

[0028] Fig. 22 is a block diagram illustrating a computing device according to an example embodiment;

[0029] Fig.23 and Fig.24 is a diagram for describing an example of a deep learning neural network structure generated by a machine learning device according to an example embodiment;

[0030] Fig.25 is a diagram illustrating an example of nodes included in a neural network according to an example embodiment;

[0031] Fig.26 is a diagram illustrating an example of a deep learning model that performs error determination in a method of managing errors of an electronic system according to example embodiments;

[0032] Fig. 27 and Fig.28 is a block diagram illustrating an electronic system according to an example embodiment; and

[0033] Fig.29 is a block diagram illustrating a data center including an electronic system according to an example embodiment. DETAILED DESCRIPTION

[0034] Various example embodiments will be described more fully below with reference to the accompanying drawings, in which some example embodiments are shown. In the accompanying drawings, like reference numerals always refer to like elements, and repeated descriptions thereof may be omitted for the sake of brevity.

[0035] In the present disclosure, the term "module" or "unit" as used in the specification indicates the software or hardware constituting the component, and the "module" or "unit" performs certain functions. However, "module" or "unit" is not meant to be limited to software or hardware. A "module" or "unit" may be configured to be stored on an addressable storage medium, or may be configured to be executed by more than one processor. Therefore, by way of example, a "module" or "unit" may include components such as software components, object-oriented software components, class components, and task components, as well as at least one of a process, a function, a property, a program, a subroutine, a program fragment, a driver, firmware, a microcode, a circuit, data, a database, a data structure, a table, an array, and a variable. Components and "modules" or "units" of functions set internally may be combined into a smaller number of components and "modules" or "units", or may be further divided into additional components and "modules" or "units".

[0036] According to an embodiment of the present disclosure, a "module" or "part" may be implemented by a processor and a memory. "Processor" is broadly interpreted in a manner including a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a controller, a microcontroller, a state machine, etc. In some contexts, a "processor" may refer to an application-specific semiconductor (ASIC), a programmable logic device (PLD), a field programmable gate array (FPGA), etc. "Processor" means a combination of processing devices, such as a combination of a DSP and a microprocessor, a combination of multiple microprocessors, a combination of more than one microprocessor and a DSP core, or any other such configuration. In addition, "memory" should be broadly interpreted in a manner including any electronic component capable of storing electronic messages. "Memory" means various types of processor-readable media, such as random access memory (RAM), read-only memory (ROM), non-volatile memory (NVRAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable rewritable read-only memory (EEPROM), cache, magnetic or optical data storage device, buffer, etc. If a processor is able to read messages from and / or write messages to a memory, the memory is said to be in electronic communication with the processor. Memory integrated into a processor is in electronic communication with the processor.

[0037] The electronic system and the method for managing errors of the electronic system according to various example embodiments can monitor uncontrollable errors in the operating system occurring in the monitored device in real time, and automatically and quickly perform necessary subsequent actions, thereby reducing unnecessary waste of personnel, time and computing resources.

[0038] Furthermore, the electronic system and the method of managing errors of the electronic system according to example embodiments may accurately determine the type of uncontrollable errors based on a plurality of error determination factors and perform corresponding follow-up measures, thereby effectively managing errors of monitored devices.

[0039] In addition, the electronic system and the method for managing errors of the electronic system according to the example embodiments can sequentially determine multiple error types according to the set priority, thereby reducing the amount of calculation required for error management and / or reducing power consumption and necessary subsequent processing. Therefore, actions can be taken more quickly.

[0040] Figure 1 is a diagram illustrating an electronic system according to an example embodiment, and Figure 2 is a flowchart illustrating a method of managing errors of an electronic system according to example embodiments. Figure 1 The electronic system 10 may be referred to as a computing system, a data processing system, etc., and may include one or more devices and / or systems.

[0041] Reference Figure 1 The electronic system 10 may include a communication network 18 , one or more management devices ( MDV1 and MDV2 ) 11 and 12 , and one or more monitored devices ( DEV1 , DEV2 , and DEV3 ) 21 , 22 , and 23 connected via the communication network 18 . Figure 1 The electronic system 10 including two management devices and three monitored devices is illustrated, but example embodiments are not limited thereto and various numbers of devices may be included in the electronic system 10 .

[0042] Each of the monitored devices 21, 22, and 23 may include a storage device STR. As will be described below, the monitored devices 21, 22, and 23 may be driven by an operating system OS and generate display images, respectively. In other words, each of the monitored devices 21, 22, and 23 may have an operating system OS executed thereon and may generate display images.

[0043] The management devices 11 and 12 and the monitored devices 21, 22 and 23 can communicate with each other via a communication network 18. The communication network 18 may include a wired network, a wireless network, or a combination thereof. For example, the communication network 18 may be implemented using Fibre Channel (FC) or Ethernet, and may be a storage-only network such as a storage area network (SAN). For example, the SAN may be an FC-SAN using an FC network, and may be implemented according to the FC protocol (FCP). As another example, the SAN may be an IP-SAN using a TCP / IP network, and may be implemented according to an iSCSI (SCSI over TCP / IP or Internet SCSI) protocol. As another example, the communication network 18 may be a general network, such as a TCP / IP network. For example, the communication network 18 may be implemented according to protocols such as FC over Ethernet (FCoE), network attached storage (NAS), and NVMe over fabric (NVMe-oF).

[0044] Each of the management devices 11 and 12 may include an error management module EMM that performs an error management method of an electronic system according to example embodiments. The error management module EMM may be implemented in the form of software, hardware, or firmware.

[0045] Reference Figure 1 and Figure 2 , the management devices 11 and 12 may periodically receive screen image data corresponding to display images generated by the monitored devices 21, 22, and 23 (S100). For example, the management devices 11 and 12 may periodically receive screen image data from the monitored devices 21, 22, and 23.

[0046] In an exemplary embodiment, the management devices 11 and 12 may periodically receive screen image data corresponding to the display image through the display output ports of the monitored devices 21, 22, and 23. For example, as will be described below with reference to Fig. 27 and Fig.28 As mentioned above, the electronic system 10 may further include a keyboard video mouse (KVM) switch connected between the management devices 11 and 12 and the display output ports of the monitored devices 21 , 22 and 23 .

[0047] In the exemplary embodiment, as will be referred to below Fig.28 As described, the electronic system 10 may further include display devices that display display images on screens and camera modules that capture screens of the display devices, respectively. In this case, the management devices 11 and 12 may periodically receive screen image data from the camera modules.

[0048] The error management module EMM of the management devices 11 and 12 may determine whether an uncontrollable error has occurred in the operating system of the monitored devices 21, 22, and 23 based on the network connection status with the monitored devices 21, 22, and 23 (S200). In an exemplary embodiment, as described below, the error management module EMM may monitor the network connection status between the monitored devices 21, 22, and 23 and the management devices 11 and 12 based on a communication protocol.

[0049] The error management module EMM may determine the type of the uncontrollable error based on the analysis result of the plurality of error determination factors and the screen image data (S300). Figures 4 to 10 Example embodiments for determining an error type are described.

[0050] The error management module EMM may transmit a request indicating a subsequent action corresponding to the type of the uncontrollable error to the monitored device where the uncontrollable error occurs (S400). The subsequent action may include various measures, such as collecting data for troubleshooting, restarting the monitored device, restarting the peripheral device, etc. The subsequent action suitable for the identified error type may be automatically performed by sending a command or request without manual access.

[0051] During the use or verification of a solution product such as a solid state drive (SSD) or universal flash storage (UFS), if the solution product causes an uncontrollable error in the operating system software of a monitored device, in the related art, an analysis engineer must visit the location. After visiting the location and identifying the defect through the output screen, subsequent actions need to be taken, such as manually extracting a memory dump or restarting the system to re-execute the assessment. When an uncontrollable error occurs in the operating system software, it is impossible to monitor from a remote location, so the engineer must personally visit the location to check whether an error occurs.

[0052] On the other hand, the electronic system and the error management method according to the exemplary embodiment can monitor the uncontrollable errors in the operating system occurring in the monitored device in real time, and automatically and quickly perform necessary subsequent actions, thereby reducing unnecessary waste of manpower and time resources. In addition, the electronic system and the error management method according to the exemplary embodiment can accurately determine the type of uncontrollable errors based on multiple error determination factors, and perform corresponding subsequent actions, thereby effectively detecting the errors of the monitored device.

[0053] Figure 3 is a flowchart illustrating a process of performing a method of managing errors of an electronic system according to example embodiments. Figure 3 An initial process for real-time monitoring according to an example embodiment is shown.

[0054] Reference Figure 1 and Figure 3 , the management devices 11 and 12 may collect device information MDI (S10) of the monitored devices 21, 22, and 23 included in the electronic system 10. The device information MDI may include the type and version of the operating system of the monitored devices 21, 22, and 23, a display image corresponding to an uncontrollable error in the operating system, the configuration of the peripheral devices, the configuration of the communication network 18, and the like.

[0055] The management devices 11 and 12 may set a plurality of error determination factors EDF and a plurality of error type ETPs (S11). For example, in some embodiments, the management devices 11 and 12 may store a plurality of error determination factors EDF associated with a plurality of error type ETPs. The plurality of error determination factors EDF may correspond to the operating systems of the monitored devices 21, 22, and 23, and appropriate factors may be selected to determine a display image corresponding to an uncontrollable error. Figure 4 Describes the settings of multiple error determination factors EDF and multiple error types ETP.

[0056] The management devices 11 and 12 may generate reference information RFI based on a plurality of error determination factors EDF and a plurality of error types ETP (S12). The reference information RFI may be implemented in the form of a referenceable table. The reference information RFI may include a value that may be used as a standard for determining whether an uncontrollable error has occurred. In an exemplary embodiment, as will be described below with reference to Figure 5 and Fig.12As described, the management devices 11 and 12 may set a priority level PRT for a plurality of error type ETPs, and the error management modules EMM of the management devices 11 and 12 may sequentially determine whether an uncontrollable error corresponding to one of the plurality of error type ETPs has occurred according to the priority level PRT. For example, in some embodiments, the management devices 11 and 12 may store a priority level PRT for a plurality of error type ETPs, and the error management modules EMM of the management devices 11 and 12 may sequentially determine whether an uncontrollable error corresponding to one of the plurality of error type ETPs has occurred according to the priority level PRT.

[0057] The management devices 11 and 12 may set a subsequent action FUA corresponding to each of the multiple error type ETPs (S13). For example, in some embodiments, the management devices 11 and 12 may store a subsequent action FUA corresponding to each of the multiple error type ETPs. The subsequent action FUA may include various actions, such as collecting data for troubleshooting, restarting the monitored device, restarting the peripheral device, etc. The subsequent action FUA may be sent to the corresponding monitored device in the form of a command or a request.

[0058] Figure 4 is a diagram illustrating an example embodiment of error determination factors and error types in a method of managing errors of an electronic system according to example embodiments.

[0059] Reference Figure 4 , the error determination factor EDF may be classified into an image type factor and a state type factor. The image type factor may include a color CLR of a displayed image, a quick response (QR) code (QRCD) included in a displayed image, a character string CHSTR included in a displayed image, and a mark MKR included in a displayed image, a change or difference of a displayed image over time (IMDFF), etc. The state type factor may include a network connection state NWST between a monitored device and a management device, a power state PWST of a monitored device, etc.

[0060] Error types ETP may include blue screen of death BSOD, boot freeze SUFZ, black screen BLKS and operating system freeze OSFZ, network error NWERR, etc.

[0061] Figure 5 is a flowchart illustrating an example embodiment of determining an error in a method of managing errors of an electronic system according to an example embodiment, and Figures 6 to 10 is a diagram illustrating an example of screen image data in a method of managing errors of an electronic system according to example embodiments.

[0062] Reference Figure 5 , including Figure 1The error management module EMM in the management devices 11 and 12 may set multiple error type ETPs for uncontrollable errors in the operating system (S410). For example, different operating systems may have different ETPs associated with them. In some embodiments, the error management module EMM may store multiple error type ETPs corresponding to uncontrollable errors of various operating systems. In some embodiments, the error management module EMM may store multiple error type ETPs corresponding to uncontrollable errors of a given operating system used by the managed monitored device. In some embodiments, the error management module EMM may set a priority level PRT for multiple error type ETPs (S420). For example, in some embodiments, the error management module EMM may store a priority level PRT for multiple error types. The error management module EMM may sequentially determine whether an uncontrollable error corresponding to one of the multiple error type ETPs has occurred in the operating system according to the priority level PRT (S430).

[0063] Figures 6 to 10 Examples of display images or screen images SIMG1 to SIMG10 are shown.

[0064] Various operating system software are installed on the system, such as Windows TM , Linux TM and Android TM . An uncontrollable error may occur when an unintentional fatal error occurs in the operating system software due to an internal software problem or a problem caused by an external device, which means that the operating system is no longer able to operate. For example, an uncontrollable error may be an error that renders the operating system inoperable, such that the operating system no longer operates, so that local operations may have difficulty overcoming the error and / or may require remote or external intervention to overcome the error. The phenomenon and type vary depending on the operating system software. In the following, the description will focus mainly on Windows TM operating system, but example embodiments are not limited to a particular operating system.

[0065] Figure 6 shows screen images SIMG1 and SIMG2 corresponding to an error type of a blue screen of death (BSOF), and Figure 7 Screen images SIMG3 and SIMG4 corresponding to the error type of the black screen (BLKS) are shown. Figure 8 Screen images SIMG5 and SIMG6 corresponding to the error type of startup freeze (SUFZ) are shown, Fig. 9 Screen images SIMG7 and SIMG8 corresponding to the error type of operating system freeze (OSFZ) are shown, and Fig.10Screen images SIMG9 and SIMG10 including a mark (MKR) are shown. Boot freeze SUFZ refers to a state in which the operation of the monitored device stops when power is applied and booting is in progress. Operating system freeze OSFZ refers to a state in which the operation stops due to reasons such as memory corruption, excessive processing capacity, etc. while the operating system is running after booting is completed. In cases such as when the monitored device is turned off or when a network error occurs, it may be difficult for the management device to check the state of the monitored device and distinguish the state from a screen image caused by an uncontrollable error in the operating system.

[0066] QR Code QRCD may exist in uncontrollable error screens, such as Figure 6 In this case, the presence or absence of the QR code (QRCD) and the code number can be collected through an open source visual library, etc. Since the QR code QRCD includes its own error correction technology, highly reliable information can be collected even when the screen information is low resolution or the screen capture angle is not straight, and can be effectively used as an error determination factor.

[0067] The string CHSTR may appear in uncontrolled error screens, such as Figure 6 and Figure 8 The screen images SIMG1, SIMG2, SIMG5, and SIMG6 in FIG. 4 are shown in FIG. 4 . In this case, optical character recognition (OCR) of an open source vision library can be used to detect the character string CHSTR. If the screen information is low resolution or the screen capture angle is not from the front, the character recognition rate may be reduced, so considering the accuracy, the presence of the character string CHSTR alone can be called a false determination factor.

[0068] The uncontrollable error screens can be mainly divided into blue screen images SIMG1 and SIMG2 and black screen images SIMG3, SIMG4, SIMG5 and SIMG6. Screen image SIMG3 is mainly black, but contains a significant percentage of blue. Through the color recognition of the open source visual library, only the main color ( Figure 4 The CLR in the image processing unit (CLC) can be classified into two types and used as an error determination factor. More detailed color specification is possible, but because the color may be displayed differently depending on the resolution of the screen image, the screen capture angle, and the lighting conditions, the detailed color specification may be less accurate.

[0069] In most cases of uncontrollable errors, the screen image remains frozen, such as Fig. 9SIMG7 and SIMG8 are shown in FIG. 1 . Therefore, it can be determined that the screen is frozen by analyzing the difference between the two screens extracted at regular time intervals, and the frozen screen can be used as an error determination factor. Using an open source image comparison tool, the image difference between the two screens over time ( Figure 4 The level of IMDFF) in can be ensured as a ratio (e.g., %), and when the difference between the screen images is below a certain level within a set time period, it can be determined that the two screens are the same.

[0070] Although the difference between the screens can be used to distinguish whether the screen is in a frozen state to some extent, there may be a case where there is almost no difference between the screens even when the operating system software is operating normally. In this case, the difference between the screens may be a mark of the difference between the screens on the monitored device caused by the operation and a mark of the change appearing on the screen at a specific time ( Figure 4 The tagging software must always remain on top of the operating system software graphical user interface (GUI) and run automatically when the system is restarted.

[0071] Fig.10 A timer type mark TMKR and a moving mark MMKR are shown as examples. The timer type mark TMKR is a mark whose number changes at regular intervals at a fixed position. In this case, the difference in the screen image over time can be determined by image comparison or OCR. The moving mark MMKR is a mark that moves at regular intervals, and the difference in the mark position in the screen image over time can be determined by image comparison.

[0072] A baseboard management controller (BMC), power measurement board, etc. can be used to ensure the power status of the monitored device ( Figure 4 PWST in), which will be referred to below Fig.14 describe.

[0073] The system's network connection status ( Figure 4 NWST in Windows TM Remote desktop technology is used to extract and can be used as an initial determining factor to try to determine uncontrollable errors.

[0074] Fig.11 is a flowchart illustrating a method of managing errors of an electronic system according to example embodiments.

[0075] Reference Fig.11 , management device (e.g. Figure 1During the standby state (STANDBY), the management device 11 waits for a specific period of time until the management device 11 receives a communication from the monitored device (e.g., Figure 1 21) The screen image data SIDT (S21) corresponding to the display image is periodically generated.

[0076] The management device 11 may determine the network connection state NWST (S22). For example, the management device 11 may determine the network connection state NWST by attempting to communicate with the communication module, which will be referred to below. Fig.14 The management device 11 may determine whether the network connection state NWST is normal (S23). If the network connection state NWST is normal (S23: Yes), the management device 11 may determine that an uncontrollable error has not occurred, and return to operation S20.

[0077] If the network connection state NWST is not normal (S23: No), the management device 11 may determine the power state PWST (S24). For example, if communication between the management device 11 and the monitored device 21 is not possible, the management device 11 may determine that the network connection state NWST is not normal. For example, in some embodiments, the management device 11 may receive information about the power state PWST from the BMC, which will be referred to below. Fig.14 describe.

[0078] The management device 11 may determine whether the power state PWST is in the power-on state PON (S25). If the power state PWST is not the power-on state PON (S25: No), the management device 11 may determine that no uncontrollable error has occurred, and return to operation S20. According to an embodiment, the power of the monitored device 21 may be set to always be in the on state, and in this case, the management device 11 may send a restart request to the monitored device 21.

[0079] If the power state PWST is the power-on state PON (S25: Yes), the management device 11 may perform image analysis (S26). For example, in some embodiments, the management device 11 may perform image analysis based on the screen image data SIDT. The image analysis may be performed based on the plurality of error determination factors EDF as described above. In an example embodiment, the management device 11 may perform image analysis to comply with the priority, as will be described below with reference to Fig.12 Described.

[0080] The management device 11 may determine whether there is a corresponding error type ETP (S27). For example, in some embodiments, the management device 11 may determine whether there is an error type ETP corresponding to the screen image data SIDT. As a result of the image analysis, if there is no corresponding error type ETP (S27: No), the management device 11 may return to operation S20. According to some example embodiments, if the management device 11 cannot determine the corresponding error type ETP, the management device 11 may determine that it is a network error NWERR and notify the administrator.

[0081] As a result of the image analysis, if the corresponding error type ETP is determined (S27: Yes), the management device 11 may determine whether there is a subsequent action FUA corresponding to the determined error type ETP (S28). If there is a corresponding subsequent action FUA (S28: Yes), the management device 11 may send a request REQ (S29). For example, the management device 11 may send a request REQ indicating the subsequent action FUA to the monitored device 21 and return to operation S20. If there is no corresponding subsequent action FUA (28: No), the management device 11 may return to operation S20.

[0082] Fig.12 is a flowchart illustrating an example embodiment of determining an error in a method of managing errors of an electronic system according to an example embodiment.

[0083] Reference Fig.12 The error management module EMM of the management device 11 may determine the type of the uncontrollable error in the order of the blue screen of death BSOD, the boot freeze SUFZ, the black screen BLKS and the operating system freeze OSFZ.

[0084] First, the error management module EMM may determine whether the error type is a blue screen of death BSOD in operation S30, and if the error type corresponds to the blue screen of death BSOD (S30: Yes), the error management module EMM may transmit a log dump request LDREQ to the monitored device 21 (S34).

[0085] Second, if the error type does not correspond to the blue screen of death BSOD (S30: No), the error management module EMM may determine whether the error type is a boot freeze SUFZ in operation S31 (S31: Yes), and if the error type corresponds to a boot freeze SUFZ, the error management module EMM may transmit a log dump request LDREQ to the monitored device 21 (S34).

[0086] Third, if the error type does not correspond to the boot freeze SUFZ (S31: No), the error management module EMM can determine whether the error type is a black screen BLKS in operation S32, and if the error type corresponds to the black screen BLKS (S32: Yes), the error management module EMM can transmit a log dump request LDREQ to the monitored device 21 (S34).

[0087] Fourth, if the error type does not correspond to the black screen BLKS (S32: No), the error management module EMM can determine whether the error type is the operating system freeze OSFZ in operation S33, and if the error type corresponds to the operating system freeze OSFZ (S33: Yes), the error management module EMM can transmit a log dump request LDREQ to the monitored device 21 (S34).

[0088] In this way, the electronic system and error management method according to example embodiments may sequentially determine a plurality of error types according to the priority of the error type (ETP), thereby reducing the amount of calculation required for error management, reducing power consumption, and quickly performing subsequent actions.

[0089] Fig.12 An example embodiment is shown in which four error types are determined in order of priority by image analysis, but the example embodiment is not limited thereto. Error determination starts in order from the highest priority to the lowest priority, and when an uncontrollable error is confirmed, error determination is terminated without further processing of the additional error type. Generally, an error type with a high accuracy of errors that can be distinguished by an error determination factor is assigned a higher priority, so once the error is determined in the priority order, it is no longer necessary to compare the conditions of the lower priority order. In addition, most errors can be identified by the error determination factor with a higher priority, and errors that are difficult to distinguish can be detected with a lower priority.

[0090] Fig.13 is a flowchart illustrating a method of managing errors of an electronic system according to example embodiments.

[0091] Reference Fig.13 , the management device 11 may periodically receive the screen image data SIDT1, and determine whether the screen image data SIDT1 includes a QR code QRCD indicating a blue screen of death BSOD based on the analysis result of the screen image data SIDT1 (S50). If the QR code QRCD is included (S50: Yes), the management device 11 may determine that the error type is a blue screen of death BSOD (S51), and transmit a log dump request LDREQ to the monitored device 21 (S52).

[0092] If the QR code QRCD is not included (S50: No), the management device 11 may determine whether the main color of the screen image data SIDT1 is blue based on the analysis result (S53). If the main color is blue (S53: Yes), the management device 11 may determine that the error type is a blue screen of death BSOD (S51), and transmit a log dump request LDREQ to the monitored device 21 (S52).

[0093] If the main color is not blue (S53: No), the management device 11 may determine whether the main color of the screen image data SIDT1 is black based on the analysis result (S54). When the main color is black (S54: Yes), the management device 11 may determine whether the screen image data SIDT1 includes the following: Figure 7 If the blue part is included (S55: Yes), the management device 11 may determine that the error type is the start freeze SUFZ (S56), and transmit a log dump request LDREQ to the monitored device 21 (S57).

[0094] If the blue part is not included (S55: No), the management device 11 may determine whether the power state of the monitored device 21 is the power-off state POFF (S58). If the monitored device 21 is not in the power-off state POFF (S58: No), the management device 11 may determine that the error type is a black screen BLKS (S59), and transmit a log dump request LDREQ to the monitored device 21 (S60). In some example embodiments, in the case of the power-off state POFF (S58: Yes), it may be determined that the monitored device 21 is in a normal state. In some embodiments, in the case of the power-off state POFF (S58: Yes), it may be determined that the monitored device 21 is in an abnormal state, and a restart request RBREQ may be sent to the monitored device 21.

[0095] If the main color is not black (S54: No), the management device 11 may receive the next screen image data SIDT2 (S61) and perform image comparison based on the screen image data SIDT1 and SIDT2. That is, the management device 11 may determine whether the screen image data SIDT1 and SIDT2 include the mark MKR based on the image comparison (S62).

[0096] If the screen image data SIDT1 and SIDT2 include the marker MKR (S62: Yes), the management device 11 may determine whether the marker MKR has changed based on the image comparison result (S63). If the marker MKR has changed (S63: Yes), the management device 11 may determine that the error type is a network error NWERR (S64) and notify the manager of an alarm (S65). The notification method may be implemented in various ways, such as a warning sound, a warning screen, and email transmission. If the marker MKR has not changed (S63: No), the management device 11 may determine that the error type is an operating system freeze OSFZ (S68), and transmit a log dump request LDREQ to the monitored device 21 (S69).

[0097] If the mark MKR is not included (S62: No), the management device 11 may calculate the image difference IMDFF of the screen image data SIDT1 and SIDT2 (S66). If the image difference IMDFF indicates that the similarity SML of the images is greater than the reference value RV (S67: Yes), the management device 11 may determine that the error type is an operating system freeze OSFZ (S68), and transmit a log dump request LDREQ to the monitored device 21 (S69). If the similarity SML is not greater than the reference value RV (S67: No), the management device 11 may determine that the error type is a network error NWERR (S70), and notify an alarm to the manager (S71).

[0098] Fig.14 is a block diagram illustrating an example embodiment of a monitored device included in an electronic system according to an example embodiment.

[0099] Reference Fig.14 , the monitored device 1000 may include a host device 1100 and a storage device 1200. For example, the monitored device 1000 may be one of electronic devices such as a desktop computer, a laptop computer, a tablet, a smart phone, a wearable device, a video game console, a workstation, one or more servers, an electric vehicle, a home appliance, a medical device, etc.

[0100] The host device 1100 includes a host processor 1110, a baseboard management controller (BMC) 1120, a communication module (CMMD) 1130, PCIe ports 1101, 1102 and 1103, a system management bus (SMBus) port 1104, an input and output port (I / O port) 1105, and a remote access port (RA port) 1106.

[0101] The host processor 1110 may include an application layer such as a host operating system (OS) and a protocol layer such as non-volatile memory express (NVMe). The host OS is driven by the host processor 1110 and may control the overall operation of the host device 1100. In other words, the host OS is executed by the host processor 1110 and may control the overall operation of the host device 1100. NVMe is driven by the host processor 1110 so that the host device 1100 can communicate with the storage device 1200. In other words, NVMe is executed by the host processor 1110 so that the host device 1100 can communicate with the storage device 1200. NVMe may be a register-level interface that manages how the host software running on the host device 1100 communicates with the storage device 1200 through a PCIe (Peripheral Component Interconnect Express) bus. The host processor 1110 may be implemented as a general-purpose processor, a dedicated processor, or an application processor including one or more processor cores.

[0102] The BMC 1120 may include an application layer such as a BMC OS, a protocol layer such as an NVMe management interface (NVMe-MI), and a transport layer such as a management component transport protocol (MCTP). The BMC OS may control the overall operation of the BMC 1120. NVMe-MI may provide a management console that supports an in-band management function, an out-of-band management function, and various OSs of the monitored device 1000 operating based on NVMe. MCTP may define a message transmission protocol.

[0103] The BMC 1120 may monitor the status of sensors installed in each hardware such as the host processor 1110, a fan, and a power supply device. For example, the BMC 1120 may collect data on the physical status of a field replaceable unit FRU (e.g., FRU1, FRU2, ..., FRUn) of the host device 1100 (or connected to the host device 1100). Here, the FRU may refer to a component that can be easily removed or replaced without replacing or repairing the entire monitored device 1000. For example, the FRU may include a fan, various sensors, a power supply, etc. In this case, the BMC 1120 may collect data on the fan speed, the temperature of each component of the host device 1100, and the power supply voltage of the power supply device (hereinafter referred to as FRU data). The BMC 1120 and the FRU may be connected via the system management bus SMBus.

[0104] The BMC 1120 may provide the FRU data to the host processor 1110 through the PCIe port 1103, the PCIe bus, and the PCIe port 1102. The host processor 1110 may provide the FRU data to the storage device 1200 through the PCIe port 1101, the PCIe bus, and the PCIe port 1201. In some embodiments, the BMC 1120 may provide the FRU data to the SMBus connected to the storage device 1200 according to a predetermined protocol.

[0105] Each of the PCIe ports 1102 and 1103 may include a physical layer and / or a logical layer configured to transmit, receive, and process data, signals, and / or packets so that the host processor 1110 and the BMC 1120 can communicate with each other. Each of the PCIe ports 1101 and 1201 may include the same or similar layers so that the host processor 1110 and the storage controller 100 can communicate with each other, and each of the SMBus 1104 and 1202 may include the same or similar layers so that the BMC 1120 and the storage controller 100 can communicate with each other. For example, each of the PCIe ports 1101, 1102, 1103, and 1201 and the SMBus ports 1104 and 1202 may include an NVMe management endpoint, wherein the NVMe management endpoint may be an MCTP endpoint.

[0106] In some embodiments, the BMC 1120 may perform a system event log function. For example, when an event occurs in which the value of data collected from a fan, power supply, etc. exceeds a threshold value and / or an event occurs such as a request to power on or off the power supply of the monitored device 1000. The log of the events that occurred may be stored in a separate memory (not shown) within the host device 1100.

[0107] Although not shown in the drawings, the monitored device 1000 may further include a working memory and a user interface. In this case, the working memory may store data used in the operation of the monitored device 1000. For example, the working memory may temporarily store data collected (or processed) by the BMC 1120 and data processed (or to be processed) by the host processor 1110. For example, the working memory may be a volatile memory (such as a static random access memory (SRAM), a dynamic RAM (DRAM), a synchronous RAM (SDRAM) and / or a phase change RAM (PRAM), a magnetoresistive RAM (MRAM)) or a non-volatile memory (such as a resistive RAM (ReRAM), a ferroelectric RAM (FRAM), etc.).

[0108] The communication module (CMMD) 1130 may support at least one of various wireless / wired communication protocols to communicate with external devices / systems of the monitored device 1000. The user interface may include various input / output interfaces to mediate communication between the user and the monitored device 1000. If an uncontrollable error occurs in the operating system of the monitored device 1000, communication with the management device may become impossible, and the aforementioned network error NWERR may occur.

[0109] The host device 1100 may be connected to input and output devices such as a display device, a keyboard, and a mouse through an input and output port 1105. The display output port may be implemented as a part of the input and output port 1105. In some embodiments, the host device 1100 may be connected to a management device through a remote access (RA) port 1106. The BMC 1120 may receive a log dump request LDREQ, a restart request RBREQ, etc. from the management device through the remote access port 1106.

[0110] The storage device 1200 may include a storage controller 100 and a non-volatile memory device (NVM) 800. The storage device 1200 may obtain FRU data through various paths. For example, the storage device 1200 may receive FRU data from the host processor 1110 through a PCIe bus connected to the PCIe port 1201. For example, the reception of FRU data may be performed according to a request from the host processor 1110. In some embodiments, when an error occurs in the storage device 1200, the storage device 1200 may access the SMBus connecting the SMBus ports 1104 and 1202, and obtain FRU data from the SMBus. The storage device 1200 may store the error information of the storage device 1200 itself and the FRU information that may be related to the error of the host device 1100 in the non-volatile memory device 800. As a result, it is easy to confirm that the error in the storage device 1200 is caused by the error in the host device 1100 through debugging.

[0111] In the present disclosure, it is described that the BMC 1120 and the FRU are connected via SMBus, and the SMBus port 1104 of the host device 1100 and the SMBus port 1202 of the storage device 1200 are connected via SMBus, but example embodiments are not limited thereto. For example, in some embodiments, the storage device 1200 and the host device 1100 may be connected via an inter-integrated circuit (I2C) bus.

[0112] Fig.15 It is shown that the Fig.14 A block diagram of an example embodiment of a storage controller in a monitored device.

[0113] Reference Fig.15The storage controller 100 may include a processor 110, a buffer memory (BUFF) 140, a log dump controller (LDC) 130, a host interface (HIF) 120, an error correction code (ECC) engine 170, a memory interface (MIF) 150, an advanced encryption standard (AES) engine 180, and an internal bus system 160 connecting the components in the storage controller 100.

[0114] The processor 110 may respond to a request from a host device (eg, Fig.14 The processor 110 may control the operation of the storage controller 100 by receiving commands from the host device 1100 in the storage controller 100. For example, the processor 110 may control the storage device (e.g., Fig.14 The operation of the storage device 1200 in the embodiment of the present invention can be controlled, and the corresponding components can be controlled by adopting firmware for operating the storage device.

[0115] The buffer memory (BUFF) 140 may store instructions and data executed and processed by the processor 110. For example, the buffer memory 140 may be implemented with a volatile memory such as a DRAM, an SRAM, a cache memory, etc.

[0116] The ECC engine 170 for error correction may perform coded modulation using Bose-Chaudhuri-Hocquenghem (BCH) codes, low-density parity-check (LDPC) codes, turbo codes, Reed-Solomon codes, convolutional codes, recursive systematic codes (RSC), trellis coded modulation (TCM), block coded modulation (BCM), etc. In some example embodiments, the ECC engine 170 may perform ECC encoding and ECC decoding using the above codes or other error correction codes.

[0117] The host interface 120 may provide a physical connection between the host device 1100 and the storage device 1200. The host interface 120 may provide an interface corresponding to a bus format of the host device 1100 for communication between the host device 1100 and the storage device 1200. In some example embodiments, the bus format of the host device 1100 may be a small computer system interface (SCSI) or a serial attached SCSI (SAS) interface. In some example embodiments, the bus format of the host device may be USB, peripheral component interconnect (PCI) Express (PCIe), Advanced Technology Attachment (ATA), Parallel ATA (PATA), SATA, Non-Volatile Memory (NVM) Express (NVMe), or other formats.

[0118] The memory interface (MIF) 150 can be used with non-volatile memory devices (e.g., Fig.14The memory interface 150 may be configured to communicate with the nonvolatile memory device 800 and / or may receive data read from the nonvolatile memory device 800. In some example embodiments, the memory interface 150 may be connected to the nonvolatile memory device 800 via one channel. In other example embodiments, the memory interface 150 may be connected to the nonvolatile memory device 800 via two or more channels. The memory interface 150 may be configured to follow a standard protocol, such as a switching or open NAND flash interface (ONFI).

[0119] The AES engine 180 may perform at least one of an encryption operation and a decryption operation on data input to the storage controller 100 using a symmetric key algorithm. The AES engine 180 may include an encryption module and a decryption module. For example, the encryption module and the decryption module may be implemented as separate modules. In another example, one module capable of performing both encryption and decryption operations may be implemented in the AES engine 180.

[0120] The log dump controller (LDC) 130 may control the log dump operation, as will be described below with reference to Fig.19 Described.

[0121] Fig.16 It is shown that the Fig.14 A block diagram of an example embodiment of a non-volatile memory device in a monitored device.

[0122] Reference Fig.16 , the nonvolatile memory device 800 may include a memory cell array 900, a page buffer circuit 810, a data input / output circuit 820, an address decoder 830, a control circuit 850, and a voltage generator 860. In some example embodiments, the nonvolatile memory device 800 may have a cell-peripheral (COP) structure in which a memory cell array is arranged above a peripheral circuit. In this case, the memory cell array 900 may be formed in a cell region CREG, and the page buffer circuit 810, the data I / O circuit 820, the address decoder 830, the control circuit 850, and the voltage generator 860 may be formed in a peripheral region PREG.

[0123] The memory cell array 900 may be coupled to the address decoder 830 via string selection lines SSL, word lines WL, and ground selection lines GSL. The memory cell array 900 may be coupled to the page buffer circuit 810 via bit lines BL. The memory cell array 900 may include memory cells coupled to the word lines WL and the bit lines BL. In some example embodiments, the memory cell array 900 may be a three-dimensional memory cell array that may be formed on a substrate in a three-dimensional structure (or a vertical structure). In this case, the memory cell array 900 may include a cell string (e.g., a NAND string) that is vertically oriented so that at least one memory cell is located above another memory cell.

[0124] The control circuit 850 may receive a command signal CMD and an address signal PADD from a memory controller, and may control the erase, program, and read operations of the nonvolatile memory device 800 in response to (or based on) at least one of the command signal CMD and the address signal PADD. The erase operation may include executing an erase cycle sequence, and the program operation may include executing a program cycle sequence. Each program cycle may include a program operation and a program verification operation. Each erase cycle may include an erase operation and an erase verification operation. The read operation may include a normal read operation and a data recovery read operation.

[0125] In some example embodiments, the control circuit 850 may generate a control signal CTL for controlling the operation of the voltage generator 860 based on the command signal CMD, may generate a page buffer control signal PBC for controlling the page buffer circuit 810, and may generate a row address R_ADDR and a column address C_ADDR based on the address signal PADD. The control circuit 850 may provide the row address R_ADDR to the address decoder 830, and may provide the column address C_ADDR to the data I / O circuit 820.

[0126] The address decoder 830 may be coupled to the memory cell array 900 through the string selection line SSL, the word line WL, and the ground selection line GSL. The voltage generator 860 may generate a word line voltage VWL for operation of the memory cell array 900 of the nonvolatile memory device 800 based on the control signal CTL and the power PWR from the memory controller. The page buffer circuit 810 may be coupled to the memory cell array 900 through the bit line BL. The page buffer circuit 810 may include a plurality of buffers. The data I / O circuit 820 may be coupled to the page buffer circuit 810 through the data line DL.

[0127] Fig.17 It is shown that the Fig.16 A block diagram of a memory cell array in a nonvolatile memory device, Fig.18 It is shown that the Fig.17A circuit diagram of the equivalent circuit of a memory block in a memory cell array.

[0128] Reference Fig.17 , the memory cell array 900 may include memory blocks BLK1 to BLKz. In some example embodiments, the memory blocks BLK1 to BLKz may be composed of Fig.16 For example, the address decoder 830 may select a specific memory block corresponding to a block address among the memory blocks BLK1 to BLKz.

[0129] Fig.18 The memory block BLKi (i is an integer from 1 to z) may be formed on the substrate in a three-dimensional structure (or vertical structure). For example, the NAND string or cell string included in the memory block BLKi may be formed in a vertical direction D3 perpendicular to the upper surface of the substrate.

[0130] Reference Fig.18 , the memory block BLKi may include NAND strings NS11 to NS33 coupled between the bit lines BL1, BL2, and BL3 and the common source line CSL. Each of the NAND strings NS11 to NS33 may include a string selection transistor SST, memory cells MC1 to MC8, and a ground selection transistor GST. Fig.18 , each of the NAND strings NS11 to NS33 is illustrated as including eight memory cells MC1 to MC8. However, example embodiments are not limited thereto, and each of the NAND strings NS11 to NS33 may include various numbers of memory cells.

[0131] Each string selection transistor SST may be connected to a corresponding string selection line (one of SSL1 to SSL3). Memory cells MC1 to MC8 may be connected to corresponding gate lines GTL1 to GTL8, respectively. Gate lines GTL1 to GTL8 may be word lines, and some of gate lines GTL1 to GTL8 may be pseudo word lines. Each ground selection transistor GST may be connected to a corresponding ground selection line (one of GSL1 to GSL3). Each string selection transistor SST may be connected to a corresponding bit line (e.g., one of BL1, BL2, and BL3), and each ground selection transistor GST may be connected to a common source line CSL.

[0132] Word lines (eg, WL1 ) having the same or similar heights may be commonly connected, and ground selection lines GSL1 to GSL3 and string selection lines SSL1 to SSL3 may be separated.

[0133] Including as reference Fig.16 , Fig.17 and Fig.18The storage device of the described nonvolatile memory device 800 may be included in the monitored devices 21, 22, and 23. If an uncontrollable error occurs in the operating system of the monitored device due to the operation of such a storage device, according to an example embodiment, log data may be protected in real time. Debugging may be performed based on log data for the storage device and the monitored device including the storage device.

[0134] Fig.19 is a diagram showing a method according to an example embodiment Fig.14 Schematic diagram of an example operation of a monitored device.

[0135] The BMC 1120 of the host device 1100 may obtain FRU data from the FRU. For example, the BMC 1120 may include a fan that dissipates heat from the host device 1100, a temperature sensor that measures the internal temperature of the host device 1100, a power supply device that supplies power to the host device 1100, etc. The FRU data may include information about the vendor, type, and status (specific value) of the FRU device. For example, if the FRU is a fan, the FRU data obtained from the fan may include the manufacturer of the fan, a value indicating that the FRU is a fan, the speed (RPM) of the fan, etc.

[0136] The BMC 1120 may perform a process of adding information about the occurrence time (i.e., a timestamp) to the acquired FRU data. The BMC 1120 may send the processed FRU data to the host processor 1110 via a bus (e.g., a PCIe bus) inside the host device 1100. Alternatively or additionally, the BMC 1120 may send the processed FRU data to an SMBus connected to the storage device 1200. Alternatively or additionally, the BMC 1120 may store the FRU data in a separate memory device within the host device 1100.

[0137] In an example embodiment, when a performance abnormality (or performance degradation) is detected in the storage device 1200, the host device 1100 may send a request (i.e., a log dump request) to the storage device 1200. Here, the request may be a request to store information related to an error of the storage device 1200 (i.e., a device log) in a second area, which may be set to be different from the first area storing user data.

[0138] The storage device 1200 may read data from the SMBus connected to the host device 1100 in response to a request from the host device 1100. The BMC 1120 may stream the FRU data to the SMBus according to a predetermined SMBus protocol, and the storage device 1200 may obtain the FRU data from the SMBus connected to the host device 1100. For example, the FRU data may include a type (a value indicating that it is a FRU), an ID (a value indicating a FRU type), a value that may confirm that there is a problem with the FRU, a timestamp TS (time of occurrence of a value), and the like.

[0139] The storage device 1200 may generate a log dump command in response to a request from the host device 1100. The log dump command may involve storing FRU data (i.e., FRU log) obtained from the SMBus and a device log related to an error in the storage device 1200 in the second area of ​​the nonvolatile memory device 800. For example, the device log may include a type (a value indicating that it is a storage device (e.g., SSD)), an ID (a number of the storage device), a value identifying a problem with the storage device, and a timestamp TS, etc.

[0140] The nonvolatile memory device 800 may store the FRU data and the device log in the second area of ​​the nonvolatile memory device 800 in response to the log dump command.

[0141] In some example embodiments, when confirming that there is a problem with the FRU, the host device 1100 may send a request to the storage device 1200. Here, the request may be a request to store information related to an error of the host device 1100 (ie, FRU data) in the storage device 1200.

[0142] The BMC 1120 may confirm that there is a problem with the FRU based on whether the FRU data obtained from the FRU is within a reference range, below a reference value, or exceeds a reference value. The BMC 1120 may send a signal indicating that there is a problem with the FRU to the host processor 1110 based on the verification result. In some example embodiments, the host processor 1110 may determine whether the FRU data received from the BMC 1120 is within a reference range, below a reference value, or exceeds a reference value. Based on this determination, it may be confirmed that there is a problem with the FRU.

[0143] If an error is confirmed in the FRU data, the host processor 1110 may send a request to the storage device 1200. For example, in addition to requesting a log dump, the request from the host device 1100 may also include storing the FRU data in the storage device 1200. Therefore, the request from the host device 1100 may involve transferring the FRU data to the storage device 1200 via the PCIe bus.

[0144] The storage controller 100 may generate a log dump command in response to a request from the host device 1100. The log dump command may be a command for storing FRU data and a device log received through the PCIe bus in the second area of ​​the nonvolatile memory device 800. The nonvolatile memory device 800 may store the FRU data and / or the device log in the second area of ​​the nonvolatile memory device 800 in response to the log dump command.

[0145] In some example embodiments, when it is confirmed that there is a problem with the FRU, the host device 1100 may send a request to the storage device 1200. Here, the request may be a request notifying that there is an error in the host device 1100. That is, the request is a simple notification that there is an error in the host device 1100, and the storage device 1200 may obtain the FRU data through a path different from the path (i.e., the PCIe bus) through which the request is received. For example, the storage device 1200 may obtain the FRU data by reading data from the SMBus connected to the host device 1100 in response to the request from the host device 1100.

[0146] The storage device 1200 may generate a log dump command in response to a request from the host device 1100. The log dump command may involve storing FRU data (ie, FRU log) obtained from the SMBus and a device log related to an error in the storage device 1200 in the second area of ​​the nonvolatile memory device 800.

[0147] BMC 1120 can receive a log dump request LDREQ from a management device via a remote access port and perform a log dump operation as described above. The stored log data can be used for troubleshooting to detect the cause of the error in the future. In some embodiments, BMC 1120 can receive a restart request RBREQ from a management device via a remote access port and control the power of the monitored device 1000 to initiate a restart.

[0148] Fig. 20 is a block diagram illustrating an example of an error management module included in a management apparatus of an electronic system according to example embodiments.

[0149] Reference Fig. 20 , the error management module EMM 300 may include an image converter (IMCON) 400 , a plurality of image analyzers 500 , and an error determination device (ERRDET) 600 .

[0150] As described above, the error management module 300 determines whether an uncontrollable error occurs in the operating system of the monitored device and the type of the uncontrollable error, and transmits requests LDREQ and RBREQ indicating subsequent actions corresponding to the type of the uncontrollable error to the monitored device.

[0151] The image converter 400 may generate a target image frame TIF to be analyzed based on the screen image data SIDT. The image converter 400 may periodically generate the target image frame TIF according to a constant sampling period determined based on the first timing control signal TM1.

[0152] The plurality of image analyzers 500 may perform analysis on the target image frame TIF using different image analysis models and generate a plurality of analysis results AR1, AR2, and AR3, respectively. The image analysis model may be determined in various ways according to the above-mentioned error determination factors. Fig. 20 Three image analyzers, ie, a first image analyzer (IMANZ1) 310, a second image analyzer (IMANZ2) 320, and a third image analyzer (IMANZ3) 330 are illustrated as an example, but example embodiments are not limited thereto. The number of image analyzers may be determined in various ways depending on the embodiment.

[0153] The first image analyzer 310 may generate a first analysis result AR1 by performing analysis on the target image frame TIF using a first image analysis model. The second image analyzer 320 may generate a second analysis result AR2 by performing analysis on the target image frame TIF using a second image analysis model. The third image analyzer 330 may generate a third analysis result AR3 by performing analysis on the target image frame TIF using a third image analysis model.

[0154] Each of the plurality of image analyzers 500 may perform independent analysis scheduling regardless of analysis results of other image analyzers, and may be selectively enabled according to analysis results of other image analyzers.

[0155] The error determination device 600 may determine whether an error has occurred and the error type ETP of the error that has occurred based on the plurality of analysis results AR1, AR2, and AR3. The error determination device 600 may send requests LDREQ and RBREQ indicating subsequent actions corresponding to the determined error type ETP to the monitored device. The error determination device 600 may operate based on the second timing control signal TM2.

[0156] Fig.21 is a diagram showing a method of including Fig. 20 A block diagram of an example of an error management module in an image converter.

[0157] Reference Fig.21 , the image converter 400 may include a receiver (RX) 410 , a sampler (SMP) 420 , a scaler (SCL) 430 , and a format converter (FRM) 440 .

[0158] The receiver 410 may receive the video stream VSTR and obtain the screen image data SIDT included in the video stream VSTR. The video stream VSTR may include the screen image data SIDT at regular intervals.

[0159] The sampler 420 may periodically sample the screen image data SIDT according to a specific sampling period and output a sampled image frame SMF.

[0160] The scaler 430 may generate a scaled image frame SCF by adjusting the size of the sampled image frame SMF. The scaler 430 may adjust the size of the frame to match the input size of the plurality of image analyzers 500 described above. For example, when the resolution required for image analysis of each image analysis model in the plurality of image analyzers 500 is 1280x720, 640x480, and 640x640, respectively, and the input sampled image frame SMF is 1920x1080, a scaling transformation matching the input requirement of each image analysis model may be performed by pixel subsampling, linear interpolation, etc.

[0161] The format converter 440 may convert the format of the scaled image frame SCF to generate a target image frame TIF to be analyzed. The format converter 440 may convert the format of the scaled image frame SCF into a format required by each image analysis model of the plurality of image analyzers 500 .

[0162] In some example embodiments, the image converter 400 may further include an image quality checker BCK that detects a blurriness of the screen image data SIDT and provides a blurriness value BLR indicating the blurriness. The blurriness value BLR may be provided to Fig. 20 The error determination device 600 may determine whether to perform an error detection operation by referring to the ambiguity value BLR.

[0163] Fig. 22 is a block diagram showing a computing device according to an example embodiment. The management device of the electronic system according to the example embodiment may be implemented as Fig. 22 A computing device, but example embodiments are not limited thereto.

[0164] Reference Fig. 22 , the computing device 2100 may include a processor 2110 , a random access memory 2120 , a device driver 2130 , a storage device 2140 , a modem 2150 , and a user interface 2160 .

[0165] At least one of the processors 2110 may execute a deep learning model (DLM) 2220 and a training control module (TCM) 2240 that controls the training of the deep learning model 2200. The training control module 2240 may train the deep learning model 2220, as described below with reference to Fig.26 described.

[0166] In some example embodiments, the deep learning model 2220 and the training control module 2240 may be implemented in the form of instructions (or program codes) executed by at least one of the processors 2110. The deep learning model 2220 and the training control module 2240 may be stored in a computer-readable recording medium. At least one processor may load the instructions (or program codes) of the deep learning model 2220 and the training control module 2240 into the random access memory 2120.

[0167] In some example embodiments, at least one processor may be manufactured to implement the deep learning model 2220 and the training control module 2240. In some example embodiments, at least one processor may be manufactured to implement various machine learning modules or deep learning models. At least one processor may implement the deep learning model 2220 and the training control module 2240 by receiving information corresponding to the deep learning model 2220 and the training control module 2240.

[0168] The processor 2110 may include at least one central processing unit (CPU) 2111, an application processor (AP), etc. The processor 2110 may also include at least one special-purpose processor, such as a neural processing unit (NPU) 2113, a neuromorphic processor (NP) 2114, a graphics processing unit (GPU) 2115, etc. The processor 2110 may include two or more processors of the same type.

[0169] The random access memory 2120 is used as an operation memory of the processor 2110, and may be used as a main memory or a system memory of the computing device 2100. The random access memory 2120 may include a volatile memory (such as a dynamic random access memory or a static random access memory) or a nonvolatile memory (such as a phase change random access memory, a ferroelectric random access memory, a magnetic random access memory, or a resistive random access memory).

[0170] The device driver 2130 may control peripheral devices such as the storage device 2140, the modem 2150, and the user interface 2160 according to a request from the processor 2110. The storage device 2140 may include a fixed storage device such as a hard disk drive, a solid state drive, or a removable storage device such as an external hard disk drive, an external solid state drive, or a removable memory card.

[0171] The modem 2150 may provide remote communication with an external device. The modem 2150 may communicate with the external device wirelessly or by wire. The modem 2150 may communicate with the external device via at least one of various communication forms such as Ethernet, Wi-Fi, LTE, and 5G mobile communication.

[0172] The user interface 2160 may receive information from the user and provide information to the user. The user interface 2160 may include at least one user output interface (such as a display 2161, a speaker 2162, etc.) and at least one user input interface (such as a mouse (mouse) 2163, a keyboard 2164, a touch input device 2165, etc.).

[0173] The instructions (or program codes) of the deep learning model 2220 and the training control module 2240 may be received through the modem 2150 and stored in the storage device 2140. The instructions (or program codes) of the deep learning model 2220 and the training control module 2240 may be stored in a removable storage device coupled to the computing device 2100. The instructions (or program codes) of the deep learning model 2220 and the training control module 2240 may be loaded from the storage device 2140 to the random access memory 2120 and then executed.

[0174] The computer program instructions, the deep learning model DLM, and the training control module TCM may be stored on a temporary computer-readable medium or a non-transitory computer-readable medium. In at least some embodiments, the result value generated by the processor or the value of the arithmetic processing performed by the processor may be stored in a temporary computer-readable medium or a non-transitory computer-readable medium. In at least some embodiments, the intermediate values ​​generated during deep learning may be stored in a temporary computer-readable medium or a non-transitory computer-readable medium. However, example embodiments are not limited thereto.

[0175] Fig.23 and Fig.24 is a diagram for describing an example of a deep learning neural network structure generated by a machine learning device according to an example embodiment.

[0176] Reference Fig.23 , the neural network may include an input layer IL, a plurality of hidden layers HL1, HL2, ..., HLn and an output layer OL.

[0177] The input layer IL may include i input nodes x1, x2, ..., xi, where i is a natural number. Input data (e.g., vector input data) X whose length is i may be input to the input nodes x1, x2, ..., xi, so that each element of the input data X is input to a corresponding one of the input nodes x1, x2, ..., xi.

[0178] The plurality of hidden layers HL1, HL2, ..., HLn may include n hidden layers, where n is a natural number, and may include a plurality of hidden nodes h 1 1 、h 1 2 、h 1 3 ,……,h 1 m 、h 2 1 、h 2 2 、h 2 3 ,……,h 2 m 、h n 1 、h n 2 、h n 3 ,……,h n m For example, the hidden layer HL1 may include m hidden nodes h 1 1 、h 1 2 、h 1 3 ,……,h 1 m , the hidden layer HL2 may include m hidden nodes h 2 1 、h 2 2 、h 2 3 ,……,h 2 m , and the hidden layer HLn may include m hidden nodes h n 1 、h n 2 、h n 3 ,……,h n m , where m is a natural number.

[0179] The output layer OL may include j output nodes y1, y2, ..., yj, providing output data Y, where j is a natural number. The output layer OL may output output data Y associated with the input data X.

[0180] Fig.23The structure of the neural network shown in can be represented by information about branches (and / or connections) between nodes shown as lines and weight values ​​assigned to each branch. Nodes within a layer may not be connected to each other, but nodes in different layers may be fully (and / or partially) connected to each other.

[0181] Each node (for example, node h 1 1 ) can receive the output of the previous node (e.g., node x1), can perform a computing operation, calculation, and / or operation on the received output, and can output the result of the computing operation, calculation, or operation as an output to the next node (e.g., node h 2 1 ). Each node can calculate a value to be output by applying a specific function (e.g., a nonlinear function) to the input.

[0182] In some example embodiments, the structure of the neural network may be set in advance, and the weight values ​​of the connections between nodes may be appropriately set using data with known answers to which class the data belongs. The data with known answers may be referred to as "training data", and the process of determining the weight values ​​may be referred to as "training". The "neural network" "learns" during the training process. The set of independently trainable structures and weight values ​​is referred to as a "model", and the process of predicting which class the input data belongs to by the model with determined weight values ​​and then outputting the predicted value is referred to as a "testing" process.

[0183] Fig.23 The neural network shown may not be suitable for processing input image data (or input sound data) because each node (e.g., node h 1 1 ) is connected to all nodes of the previous layer (e.g., nodes x1, x2, ..., xi included in layer IL), and then the number of weighted values ​​increases dramatically as the size of the input image data increases. Therefore, a convolutional neural network ("CNN") implemented by combining a filtering technique with a neural network has been studied so that a two-dimensional image (e.g., input image data) is effectively trained by a convolutional neural network.

[0184] Reference Fig.24 , a convolutional neural network (CNN) may include multiple layers CONV1, RELU1, CONV2, RELU2, POOL1, CONV3, RELU3, CONV4, RELU4, POOL2, CONV5, RELU5, CONV6, RELU6 and POOL3.

[0185] and Fig.23Unlike the neural network in , each layer of the convolutional neural network may have three dimensions of width, height, and depth, and therefore the data input to each layer may be volumetric data with three dimensions of width, height, and depth.

[0186] Each of the convolution layers CONV1, CONV2, CONV3, CONV4, CONV5, and CONV6 may perform a convolution operation on the input volume data. For example, in image processing, a convolution operation represents an operation of processing image data based on a mask having weighted values, and obtaining an output value by multiplying the input value by the weighted value and adding the total multiplied value. The mask may be referred to as a filter, a window, and / or a kernel.

[0187] In more detail, the parameters of each convolutional layer may include (and / or contain) a set of learnable filters. Each filter may be small in space (e.g., along the width and height), but may extend through the entire depth of the input volume. For example, during a forward pass, each filter may slide (e.g., convolve) over the width and height of the input volume, and a dot product may be calculated between the entries of the filter and the input at any position. As the filter slides over the width and height of the input volume, a two-dimensional activation map may be generated that gives the response of the filter at each spatial position. As a result, an output volume may be generated by stacking these activation maps along the depth dimension. For example, if input volume data having a size of 32×32×3 passes through a convolutional layer CONV1 having four filters with zero padding, the output volume data of the convolutional layer CONV1 may have a size of 32×32×12 (e.g., the depth of the volume data increases).

[0188] Each of the rectified linear unit (RELU) layers RELU1, RELU2, RELU3, RELU4, RELU5, and RELU6 may perform a rectified linear unit operation corresponding to an activation function defined by, for example, a function f(x)=max(0,x) (e.g., for all negative inputs x, the output is zero). For example, if input volume data having a size of 32×32×12 passes through the RELU layer RELU1 to perform the rectified linear unit operation, the output volume data of the RELU layer RELU1 may have a size of 32×32×12 (e.g., maintaining the size of the volume data).

[0189] Each of the pooling layers POOL1, POOL2, and POOL3 may perform a downsampling operation on the input volume data along the spatial dimensions of width and height. For example, four input values ​​arranged in a 2×2 matrix form may be converted into one output value based on a 2×2 filter. For example, the maximum value of the four input values ​​arranged in a 2×2 matrix form may be selected based on a 2×2 maximum pool, or the average value of the four input values ​​arranged in a 2×2 matrix form may be obtained based on a 2×2 average pool. For example, if input volume data having a size of 32×32×12 passes through a pooling layer POOL1 having a 2×2 filter, the output volume data of the pooling layer POOL1 may have a size of 16×12×12 (e.g., the width and height of the volume data are reduced, and the depth of the volume data is maintained).

[0190] Generally, one convolution layer (e.g., CONV1) and one RELU layer (e.g., RELU1) may form a pair of CONV / RELU layers in a convolutional neural network, the paired CONV / RELU layers may be repeatedly arranged in the convolutional neural network, and a pooling layer may be periodically inserted into the convolutional neural network, thereby reducing characteristics of input data X. The type and number of layers included in the convolutional neural network may be variously changed.

[0191] Example embodiments of deep learning models are not limited to specific neural networks. For example, the deep learning model may include PNN (perceptual neural network), CNN (convolutional neural network), R-CNN (region with convolutional neural network), RPN (region proposal network), RNN (recurrent neural network), S-DNN (stacked deep neural network), S-SDN (state space dynamic neural network), deconvolution network, DBN (deep belief network), RBM (restricted Boltzmann machine), full convolution network, LSTM (long term memory) network, classification network, BNN (Bayesian neural network), etc. At least one.

[0192] Fig.25 is a diagram illustrating an example of nodes included in a neural network.

[0193] Fig.25 An example node operation performed by a node ND in a neural network is shown. When N inputs a1 to aN are provided to the node ND, the node ND may multiply the N inputs a1 to aN and the corresponding N weights w1 to wN, respectively, may add the N values ​​obtained by the multiplication, may add an offset "b" to the added value, and may generate an output value by applying the value to which the offset "b" is added to a specific function "σ". A learning operation may be performed based on training data to update all nodes in the neural network.

[0194] In the case of deep learning-based image analysis, a sufficient amount of training data and / or learning data may be utilized (and / or required) in the training of the deep learning model (and / or deep learning module). For example, various types of training data may be utilized (and / or required) to prevent overfitting during training and to enhance the performance of the deep learning model.

[0195] Fig.26 is a diagram illustrating an embodiment of a deep learning model for performing error determination in a method of managing errors of an electronic system according to an example embodiment. Fig.26 In the figure, for ease of illustration, the specific configuration of the deep learning model is omitted, and only the input layer IL receiving input data and the output layer OL providing output data are shown.

[0196] Reference Fig.26 , can train and generate deep learning model DLM, deep learning model DLM can be replaced as above Figure 3 The table type reference information RFI and Fig. 20 At least a portion of the error management module 300.

[0197] In this case, the input data of the deep learning model DLM includes one or more temporally continuous screen image data SIDT1 and SIDT2, and the output data of the deep learning model DLM includes the estimated error type ETP. Using the deep learning model DLM learned in this way, it is possible to determine whether an uncontrollable error has occurred in the operating system of the monitored device and determine the type of the uncontrollable error.

[0198] Fig. 27 and Fig.28 is a block diagram illustrating an electronic system according to example embodiments.

[0199] Reference Fig. 27 , the electronic system 3000 includes a plurality of management devices (MDV1, MDV2, and MDVm) 11, 12, and 13, a plurality of switches (SW) 251, 252, and 253, and a plurality of monitored devices (DEV11 to DEVmk) 3200. In some example embodiments, the plurality of switches 251, 252, and 253 may be keyboard video mouse (KVM) switches connected between display output ports 3210 of the plurality of monitored devices 3200 and the management devices 11, 12, and 13. The plurality of switches 251, 252, and 253 may be connected to the plurality of management devices 11, 12, and 13 via a communication network 18. Fig. 27As shown, in some example embodiments, the first group of monitored devices 3110 can be connected to the management device 11 via the switch 251, and the second group of monitored devices 3120 can be connected to the switch 252, and the mth group of monitored devices 3130 can be connected to the management device 13 via the switch 253.

[0200] Reference Fig.28 , the electronic system 4000 includes multiple management devices (MDV1 and MDVm) 11 and 13, multiple switches (SW) 251 and 253, multiple monitored target devices (DEV11 to DEVmk) 4200, multiple display devices (DIS) 4300, and multiple camera modules (CAM) 4400. The multiple display devices 4300 can display corresponding display images on corresponding screens of the display devices 4300, and the multiple camera modules 4400 can capture the screens of the multiple display devices 4300, respectively. In this case, the management devices 11 and 13 can periodically receive the above-mentioned screen image data from the multiple camera modules 4400 through the switches 251 and 253. The multiple switches 251 and 253 can be connected to the multiple management devices 11 and 13 through the communication network 18. Fig.28 As shown, the camera module 4113 capturing the screen of the display device 4112 of the first group of monitoring target devices 4111 is connected to the management device 11 through the switch 251. The camera module 4133 capturing the screen of the display device 4132 of the mth group of monitored devices 4131 can be connected to the management device 13 through the switch 253.

[0201] like Fig. 27 and Fig.28 As shown, the KVM can be connected to all server systems deployed in a laboratory, for example, to periodically extract screen output information from a remote location, and through image analysis of the screen output information and additional system information according to the example embodiments described above, uncontrollable errors in the operating system can be identified and subsequent actions can be performed without an engineer's laboratory visit.

[0202] Example embodiments may be applied to a data center server system environment. The data center determines the communication status of each server and detects server anomalies. Screen information may be extracted by accessing an IP-KVM connected to a server where an error is detected. Based on the additional information and image processing information, the presence and type of a predefined uncontrollable error may be determined. In the event of an error, predefined subsequent actions may be performed, such as a memory dump, a system restart, status, etc.

[0203] like Fig.28As shown, in a laptop-based environment where screen information cannot be extracted via a KVM, a monitoring system can be placed per IP network camera to periodically extract screen output information from a remote location.

[0204] Fig.29 is a block diagram illustrating a data center including an electronic system according to an example embodiment.

[0205] In some example embodiments, the system described above with reference to the drawings may be used as an application server and / or a storage server and included in the data center 5000. Error management according to example embodiments may be applied to each of the application server and / or the storage server.

[0206] Reference Fig.29 , the data center 5000 can collect various data fragments and provide services, and is also called a data storage center. For example, the data center 5000 may be a system configured to operate a search engine and a database or a computing system used by a company such as a bank or a government agency. Fig.29 As shown, the data center 5000 may include application servers 50_1 to 50_n and storage servers 60_1 to 60_m (wherein each of m and n is an integer greater than 1). According to embodiments, the number n of application servers 50_1 to 50_n and the number m of storage servers 60_1 to 60_m may be selected differently. In some example embodiments, the number n of application servers 50_1 to 50_n may be different from the number m of storage servers 60_1 to 60_m.

[0207] The application servers 50_1 to 50_n may include any one or any combination of processors 51_1 to 51_n, memories 52_1 to 52_n, switches 53_1 to 53_n, network interface controllers (NICs) 54_1 to 54_n, and storage devices 55_1 to 55_n. The processors 51_1 to 51_n may control all operations of the application servers 50_1 to 50_n, access the memories 52_1 to 52_n, and execute instructions and / or data loaded in the memories 52_1 to 52_n. Non-limiting examples of the memories 52_1 to 52_n may include DDR SDRAM, high bandwidth memory (HBM), hybrid memory cube (HMC), dual inline memory module (DIMM), Optane DIMM, or non-volatile DIMM (NVDI IMM).

[0208] According to example embodiments, the number of processors and memories included in the application servers 50_1 to 50_n may be selected differently according to the embodiment. In some embodiments, the processors 51_1 to 51_n and the memories 52_1 to 52_n may provide a processor-memory pair. In some embodiments, the number of processors 51_1 to 51_n may be different from the number of memories 52_1 to 52_n. The processors 51_1 to 51_n may include a single-core processor or a multi-core processor. In some embodiments, as Fig.29 As shown by the dotted lines in FIG. 1 , the storage devices 55_1 to 55_n may be omitted from the application servers 50_1 to 50_n. According to the embodiment, the number of storage devices 55_1 to 55_n included in the application servers 50_1 to 50_n may be selected differently. The processors 51_1 to 51_n, the memories 52_1 to 52_n, the switches 53_1 to 53_n, the NICs 54_1 to 54_n and / or the storage devices 55_1 to 55_n may communicate with each other through the links described above with reference to the accompanying drawings.

[0209] The storage servers 60_1 to 60_m may include any one or any combination of processors 61_1 to 61_m, memories 62_1 to 62_m, switches 63_1 to 63_m, NICs 64_1 to 64_n, and storage devices 65_1 to 65_m. The processors 61_1 to 61_m and memories 62_1 to 62_m may operate similarly to the processors 51_1 to 51_n and memories 52_1 to 52_n of the above-mentioned application servers 50_1 to 50_n.

[0210] The application servers 50_1 to 50_n can communicate with the storage servers 60_1 to 60_m through the network 70. In some embodiments, the network 70 can be implemented using Fiber Channel (FC) or Ethernet. FC can be a medium for relatively high-speed data transmission. An optical switch that provides high performance and high availability can be used as FC. According to the access method of the network 70, the storage servers 60_1 to 60_m can be provided as a file storage unit, a block storage unit, or an object storage unit.

[0211] In some example embodiments, the network 70 may be a storage-only network, such as a storage area network (SAN). For example, the SAN may be an FC-SAN that may be implemented using an FC network and using an FC protocol (FCP). In another case, the SAN may be an Internet Protocol (IP)-SAN that uses a Transmission Control Protocol / Internet Protocol (TCP / IP) network and is implemented according to a SCSI or Internet SCSI (iSCSI) protocol over TCP / IP. In some embodiments, the network 70 may be a general purpose network, such as a TCP / IP network. For example, the network 70 may be implemented according to protocols such as FC over Ethernet (FCoE), Network Attached Storage (NAS), Non-Volatile Memory Express (NVMe) over Fabric (NVMe-oF).

[0212] The application server 50_1 and the storage server 60_1 will be mainly described, but it may be noted that the description of the application server 50_1 may also be applied to another application server (eg, 50_n), and the description of the storage server 60_1 may also be applied to another storage server (eg, 60_m).

[0213] The application server 50_1 may store data requested to be stored by a user or client in one of the storage servers 60_1 to 60_m via the network 70. In some example embodiments, the application server 50_1 may obtain data requested to be read by a user or client from one of the storage servers 60_1 to 60_m via the network 70.

[0214] The application server 50_1 may access the memory 52_n and / or the storage device 55_n included in another application server 50_n through the network 70, and / or access the memory 62_1 to 62_m and / or the storage device 65_1 to 65_m included in the storage servers 60_1 to 60_m through the network 70. Therefore, the application server 50_1 may perform various operations on the data stored in the application servers 50_1 to 50_n and / or the storage servers 60_1 to 60_m. For example, the application server 50_1 may execute an instruction to migrate or copy data between the application servers 50_1 to 50_n and / or the storage servers 60_1 to 60_m. In this case, the data may be migrated to the memory 52_1 to 52_n of the application servers 50_1 to 50_n through the memory 62_1 to 62_m of the storage servers 60_1 to 60_m or directly from the storage devices 65_1 to 65_m of the storage servers 60_1 to 60_m. In some embodiments, data migrated over network 70 may be encrypted data for security or privacy reasons.

[0215] In the storage server 60_1, the interface IF can provide a physical connection between the processor 61_1 and the controller CTRL and a physical connection between the NIC 64_1 and the controller CTRL. For example, the interface IF can be implemented using a direct attached storage (DAS) method, in which the storage device 65_1 is directly connected to a dedicated cable. For example, the interface IF can be implemented using various interface methods, such as Advanced Technology Attachment (ATA), Serial ATA (SATA), External SATA (e-SATA), Small Computer Interface (SCSI), Serial Attached SCSI (SAS), PCI, PCIe, NVMe, IEEE 1394, Universal Serial Bus (USB), Secure Digital (SD) Card, Multimedia Card (MMC), Embedded MMC (eMMC), UFS, Embedded UFS (eUFS) and Compact Flash (CF) Card Interface.

[0216] In the storage server 60_1 , the switch 63_1 may selectively connect the processor 61_1 to the storage device 65_1 or selectively connect the NIC 64_1 to the storage device 65_1 based on the control of the processor 61_1 .

[0217] In some example embodiments, the NIC 64_1 may include a network interface card and a network adapter. The NIC 54_1 may be connected to the network 70 via a wired interface, a wireless interface, a Bluetooth interface, or an optical interface. The NIC 54_1 may include an internal memory, a digital signal processor (DSP), and a host bus interface, and is connected to the processor 61_1 and / or the switch 63_1 via the host bus interface. In some embodiments, the NIC 64_1 may be integrated with any one or any combination of the processor 61_1, the switch 63_1, and the storage device 65_1.

[0218] In the application servers 50_1 to 50_n or the storage servers 60_1 to 60_m, the processors 51_1 to 51_m and 61_1 to 61_n may send commands to the storage devices 55_1 to 55_n and 65_1 to 65_m or the memories 52_1 to 52_n and 62_1 to 62_m, and program or read data. In this case, the data may be data whose errors are corrected by an error correction code (ECC) engine. The data may be data processed using a data bus inversion (DBI) or a data mask (DM), and include cyclic redundancy code (CRC) information. The data may be encrypted data for security or privacy.

[0219] In response to the read command received from the processors 51_1 to 51_m and 61_1 to 61_n, the storage devices 55_1 to 55_n and 65_1 to 65_m may send a control signal and a command / address signal to a nonvolatile memory device (e.g., a NAND flash memory device) NVM. Therefore, when reading data from the nonvolatile memory device NVM, a read enable signal may be input as a data output control signal to output data to the DQ bus. The data strobe signal may be generated using a read enable signal. The command and address signals may be latched according to the rising edge or falling edge of the write enable signal.

[0220] The controller CTRL may control all operations of the storage device 65_1. In an embodiment, the controller CTRL may include a static RAM (SRAM). The controller CTRL may write data to the nonvolatile memory device NVM in response to a write command, or read data from the nonvolatile memory device NVM in response to a read command. For example, a write command and / or a read command may be generated based on a request provided from a host (e.g., a processor 61_1 of a storage server 60_1, a processor 61_m of another storage server 60_m, or processors 51_1 to 51_n of application servers 50_1 to 50_n). The buffer BUF may temporarily store (or buffer) data to be written to the nonvolatile memory device NVM or data read from the nonvolatile memory device NVM. In some embodiments, the buffer BUF may include a DRAM. The buffer BUF may store metadata. Metadata may refer to user data or data generated by the controller CTRL to manage the nonvolatile memory device NVM. The storage device 65_1 may include a security element (SE) for security or confidentiality.

[0221] According to an example embodiment, the application servers 50_1 to 50_n may include an error management module EMM. The error management module EMM may be used to monitor operating system errors on the storage servers 60_1 to 60_m and automatically perform subsequent actions.

[0222] Those skilled in the art will appreciate that the exemplary embodiments may be implemented in the form of systems, methods, products including computer-readable program codes stored in computer-readable media, etc. The computer-readable program codes may be provided to processors of various computers or other data processing devices. The computer-readable medium may be a computer-readable signal medium or a computer-readable recording medium. The computer-readable recording medium may be any tangible medium that can store or contain a program in an instruction execution system, device, or apparatus, or that is connected to an instruction execution system, device, or apparatus.

[0223] Example embodiments may be applied to any electronic device and system. For example, example embodiments may be applied to systems such as mobile phones, smart phones, personal digital assistants (PDAs), portable multimedia players (PMPs), digital cameras, video cameras, personal computers (PCs), server computers, workstations, laptop computers, digital TVs, set-top boxes, portable game consoles, navigation systems, wearable devices, Internet of Things (IoT) devices, Internet of Everything (IoE) devices, e-books, virtual reality (VR) devices, augmented reality (AR) devices, server systems, automotive driving systems, data centers, etc.

[0224] The above is a description of example embodiments and should not be construed as limiting thereof. Although a few example embodiments have been described, those skilled in the art will readily appreciate that many modifications may be made in the example embodiments without substantially departing from the scope of the appended claims.

Claims

1. An electronic system comprising: a monitored device configured to operate according to the operating system and generate a display image; as well as A management device, which is connected to the monitored device via a communication network and is configured to: periodically receiving screen image data corresponding to the display image from the monitored device; determining, based on a network connection status with the monitored device, whether an error has occurred in the operating system of the monitored device causing the operating system of the monitored device to become inoperable; determining a type of the error based on a plurality of error determination factors and an analysis result of the screen image data; as well as A request is transmitted to the monitored device indicating a subsequent action to be taken to resolve the error, the subsequent action corresponding to the type of the error.

2. The electronic system as claimed in claim 1, wherein: The management device is configured to store a plurality of error types and determine whether the error corresponds to one of the plurality of error types.

3. The electronic system as claimed in claim 2, wherein: The management device is configured to store priorities of the plurality of error types, and sequentially determine whether the error corresponds to the plurality of error types based on the priorities.

4. The electronic system as claimed in claim 2, wherein: The management device is configured to transmit at least one of a log dump request and a restart request to the monitored device based on the type of the error when the error corresponds to one of the plurality of error types, The log dump request instructs the monitored device to store the log data in the monitored device or to transmit the log data to the management device, and The restart request indicates that the monitored device restarts.

5. The electronic system as claimed in claim 1, wherein: The type of error includes one of a blue screen of death, a boot freeze, a black screen, and an operating system freeze.

6. The electronic system as claimed in claim 5, wherein: The type of the error is sequentially determined according to the order of the blue screen of death, the boot freeze, the black screen, and the operating system freeze.

7. The electronic system as claimed in claim 5, wherein: The management device is configured to transmit a log dump request to the monitored device when the type of the error corresponds to one of the blue screen of death, the boot freeze, the black screen, and the operating system freeze, The log dump request instructs the monitored device to store the log data in the monitored device or to transmit the log data to the management device.

8. The electronic system as claimed in claim 1, wherein: The management device is configured to monitor the network connection state between the monitored device and the management device based on a communication protocol, and determine that the error has not occurred when communication is normally performed between the monitored device and the management device according to the communication protocol.

9. The electronic system as claimed in claim 1, wherein: The management device is configured to monitor a power state of the monitored device, and determine that the error does not occur when the monitored device is in a power-off state.

10. The electronic system of claim 1, wherein: The management device is configured to periodically receive the screen image data through an output port of the monitored device.

11. The electronic system of claim 1 , further comprising: A keyboard video mouse switch connected between the management device and the display output port of the monitored device, Wherein, the management device is configured to periodically receive the screen image data through the keyboard video mouse switch.

12. The electronic system of claim 1, wherein: The monitored device comprises: A display device configured to display the display image on a screen; and a camera module configured to capture an image of the screen, Wherein, the management device is configured to periodically receive the screen image data from the camera module.

13. The electronic system of claim 1, wherein: The multiple error determination factors include the color of the displayed image, the quick response code included in the displayed image, the character string included in the displayed image, the mark included in the displayed image, the difference in the displayed image over time, the network connection status between the monitored device and the management device, and the power status of the monitored device.

14. The electronic system of claim 1, wherein: The management device is configured to determine whether the error occurs and the type of the error using a deep learning model that takes the screen image data as input and outputs the type of the error.

15. An electronic system comprising: a plurality of monitored devices, each of the plurality of monitored devices being configured to operate according to an operating system, and each of the plurality of monitored devices being configured to generate a plurality of display images; as well as a management device connected to the plurality of monitored devices via a communication network and configured to: periodically receiving a plurality of screen image data corresponding to the plurality of display images from the plurality of monitored devices; determining, based on a network connection status with the plurality of monitored devices, whether an error occurs in an operating system of one of the plurality of monitored devices that renders the operating system of the one of the plurality of monitored devices inoperable; determining a type of the error based on a plurality of error determination factors and analysis results of a plurality of screen image data of the one of the plurality of monitored devices; as well as A request is transmitted to the one of the plurality of monitored devices indicating a subsequent action to be taken to resolve the error, the subsequent action corresponding to the type of the error.

16. The electronic system of claim 15, further comprising: a keyboard video mouse switch connected between the management device and the display output ports of the plurality of monitored devices, Wherein, the management device is configured to periodically receive the plurality of screen image data from the keyboard video mouse switch.

17. The electronic system of claim 15, wherein: The plurality of monitored devices include: a plurality of display devices, the plurality of display devices being configured to display the plurality of display images on screens respectively; and a plurality of camera modules, the plurality of camera modules being configured to respectively capture images of the screen, Wherein, the management device is configured to periodically receive the plurality of screen image data from the plurality of camera modules.

18. The electronic system of claim 15, wherein: The management device is configured to store a plurality of error types and a plurality of priorities of the plurality of error types, and It is sequentially determined whether the error corresponds to the plurality of error types based on the plurality of priorities.

19. A method for managing errors of a monitored device, the monitored device operating according to an operating system and configured to generate a display image, the method being performed by a management device connected to the monitored device via a communication network, the method comprising: periodically receiving screen image data corresponding to the display image from the monitored device; determining, based on a network connection status with the monitored device, whether an error has occurred in the operating system of the monitored device that renders the operating system of the monitored device inoperable; determining a type of the error based on a plurality of error determination factors and an analysis result of the screen image data; as well as A request is transmitted to the monitored device indicating a subsequent action to be taken to resolve the error, the subsequent action corresponding to the type of the error.

20. The method of claim 19, wherein: Determining the type of error includes: It is sequentially determined whether the error corresponds to one of the plurality of error types based on priorities of the plurality of error types.

Citation Information

Patent Citations

  • Apparatus for preventing animal rising of electric pole

    KR1020230090907A