KR101174238B1 - Automated machine having self diagnosing error function and method for diagnosing error - Google Patents

Abstract

The present invention relates to an automated device having a self-diagnostic function and a method for diagnosing the same. According to the present invention, when an XFS-based automation device fails during operation, an application (AP) for operating the automation device, a plurality of service providers each receiving a command from an AP and driving a plurality of devices, and the An XFS manager connecting an application and a service provider and a diagnosis of the device are requested, and a diagnosis platform provided in the automation device performs the diagnosis according to the request of the diagnosis of the failure. Fault diagnosis for the application, service provider, XFS manager and device is performed by the diagnostic platform through different communication paths. The fault diagnosis results for the above units are stored in a predetermined memory. After that, if a diagnosis item for each unit is stored in the memory, the diagnosis platform displays the information to the administrator. According to the present invention as described above, even if a failure occurs during operation by configuring the automation device with units manufactured by different manufacturers, it is possible to quickly identify the unit in which the failure occurs, it is possible to quickly recover the failure and responsible for the manufacturer of the unit There is an advantage of being clear.

Description

AUTOMATIC MACHINE HAVING SELF DIAGNOSING ERROR FUNCTION AND METHOD FOR DIAGNOSING ERROR}

The present invention relates to an automation device, and in particular, when a failure occurs in an XFS (Extension for Financial Service) based automation device, the automation device having its own failure diagnosis function to guide the information on the unit that caused the failure and its It relates to a method of diagnosing disability.

The automation device is composed of a plurality of device aggregates. The device refers to those provided to an automated device for performing a certain transaction, such as a keypad device, a customer service device, a card reader device, a media recognition device, and the like. And the device is equipped with the appropriate device is adopted according to the task and type of the automation equipment.

In particular, in XFS-based automation, the CEN / XFS standard is provided which defines instructions for driving the devices. The CEN / XFS standard defines a user interface to provide consistent control over the driving of these devices.

Accordingly, the XFS-based automation device connects an application (Application: AP) for operating the automation device, a service provider provided to control the operation of the various devices described above, and the AP and the SP. It will include the XFS Manager. The service provider is provided for each device.

On the other hand, the automated device having an XFS-based configuration can use the changed device immediately even if the device in use is changed to a device of another manufacturer without further developing or changing an application according to the firmware of the changed device. In other words, the XFS-based automation device independently controls a plurality of devices using XFS commands without using respective firmware commands provided by a vendor for each device for a plurality of devices.

However, the conventional XFS-based automation device poses the following problems.

That is, the application, the XFS manager, the service provider, and the plurality of devices constituting the automation device are manufactured by a single manufacturer, and even if a failure occurs, the active countermeasure is possible and the failure can be easily recovered.

On the other hand, when the units, that is, the application, the XFS manager, the service provider, and the manufacturer of the device, are different from each other, a problem may occur that the cause of the failure may not be easily determined. That is, even if a failure occurs in one unit, the manufacturer who manufactures the unit may claim that the failure does not occur in his unit. For example, in an application manufactured by Company A, the service provider and device of Company B operate normally. However, the service provider and the device provided by Company C may cause a failure. The device fails, but C's service providers and modules are likely to work.

Therefore, it is not easy to find the failed unit, and it is difficult to identify the responsible material for each manufacturer. For this reason, the time and cost for disaster recovery may be longer than necessary when the automation equipment is manufactured by one manufacturer.

This problem results in worse if the failure occurs during a given transaction time. In other words, it takes more time to complete the recovery, so that the customer is unable to carry out his transaction, which increases the reliability of the device operation.

Accordingly, an object of the present invention is to solve the above problems, and has a self-diagnostic function that makes it easy to identify the unit causing the failure in the XFS-based automated device and to allow the administrator to recognize the information about the unit. It is to provide an automated device and a method for diagnosing the failure thereof.

According to a feature of the present invention for achieving the above object, an application (AP) for operating the drive of the automation device; A plurality of service providers receiving commands from the AP and driving the plurality of devices, respectively; An XFS manager connecting the application and a service provider; A request unit for requesting a failure diagnosis for the application, the service provider, the XFS manager, and the device when the failure of the automation device occurs; A diagnostic platform for separately diagnosing failure of the application, service provider, XFS manager, and device by the request unit; And a display unit for displaying a diagnosis result of the diagnosis platform, wherein the diagnosis platform includes a first diagnosis unit for diagnosing the application, a second diagnosis unit for diagnosing the service provider, and the XFS manager. And a third diagnosis part for diagnosing the fourth diagnosis part for diagnosing the device.

A first memory for storing a diagnosis result of the first to fourth diagnosis units of the diagnostic platform, a second memory for storing a diagnosis method for the XFS manager, and a failure of an automation device when performing a diagnosis for the service provider The apparatus may further include a third memory configured to store the XFS instruction within a predetermined time before the occurrence time.

The first diagnosis unit diagnoses whether an application has a failure or transmits a message transmitted to the application by an XFS command transmitted from the application while being connected to the application and the XFS manager by modifying a registry value; The response of the message is checked within a preset timeout to diagnose whether the application is faulty.

The second diagnosis unit diagnoses a failure of the XFS manager by referring to a diagnosis method stored in the second memory.

The third diagnosis unit diagnoses a failure of a service provider by using an XFS command stored in the third memory, and the failure diagnosis is repeatedly performed until all XFS commands stored in the third memory are deleted. .

The fourth diagnosis unit diagnoses a failure by directly using a firmware command of the device in a state of directly connecting with the device.

According to another feature of the invention, the step of generating a failure diagnosis request when the failure of the automated device; A diagnostic platform performing a failure diagnosis on an application, an XFS manager, a service provider, and a device of the automation device according to the failure diagnosis request and storing a failure diagnosis result; And providing the stored diagnosis result of the diagnosis platform, wherein the diagnosis platform includes a first diagnosis part for diagnosing the application, a second diagnosis part for diagnosing the service provider, and the XFS. And a third diagnosis part for diagnosing the manager and a fourth diagnosis part for diagnosing the device.

The fault diagnosis result is provided at a time after the fault diagnosis for the application, the XFS manager, the service provider, and the device are all completed.

The fault diagnosis result is provided only when the fault diagnosis item is stored in the memory.

According to the present invention, when a failure occurs while the automation device is running, the diagnostic platform diagnoses whether a failure occurs in the system for each unit of the application, the XFS manager, the service provider, and the device of the automation device, and fails for the failed unit. After the information is stored in memory, it is provided for administrators to check.

Therefore, when each unit is manufactured by different manufacturers, it is possible to quickly identify the unit in which the failure of the automation device occurs, and it is possible to proactively deal with the failure recovery.

Not only can this be convenient for the customer, it can also be clear that each unit is responsible for the failure.

1 is a block diagram of an automated device having a self-diagnostic function according to a preferred embodiment of the present invention
2A and 2B are flow charts illustrating fault diagnosis of an application by the diagnostic platform shown in FIG.
FIG. 3 is a flow chart illustrating fault diagnosis of the XFS manager by the diagnostic platform shown in FIG.
4 is a flow chart illustrating fault diagnosis of a service provider by the diagnostic platform shown in FIG.
FIG. 5 is a flow chart illustrating fault diagnosis of a device by the diagnostic platform shown in FIG.

Hereinafter, some embodiments of the present invention will be described in detail with reference to exemplary drawings. In adding reference numerals to the components of each drawing, it should be noted that the same reference numerals are assigned to the same components as much as possible even though they are shown in different drawings. In addition, in describing the embodiments of the present invention, when it is determined that a detailed description of a related well-known configuration or function interferes with the understanding of the embodiments of the present invention, the detailed description thereof will be omitted.

In addition, in describing the components of the embodiment of the present invention, terms such as first, second, A, B, (a), and (b) may be used. These terms are intended to distinguish the constituent elements from other constituent elements, and the terms do not limit the nature, order or order of the constituent elements. When a component is described as being "connected", "coupled", or "connected" to another component, the component may be directly connected or connected to the other component, Quot; may be "connected," "coupled," or "connected. &Quot;

Next, an embodiment of the present invention will be described.

1 is a block diagram of an automated device having a self-diagnostic function according to a preferred embodiment of the present invention.

1, an application (AP) 102, which is a program for operating the automation device 100, is provided. The application 102 is composed of a customer reception unit, a professional transmission and reception unit between the server and the automation device, an operation program unit, etc., and functions to control the automation device 100 as a whole. The XFS-based automation device 100 calls the API of the XFS manager using the commands defined in the XFS protocol to control the device 108 that is actually driven for a given transaction.

An XFS manager 104 is provided that is a DLL (Dynamic Linking Library) that performs a connection operation between the application and a service provider (SP), which will be described later.

A service provider 106 is provided that drives a plurality of devices 108 described below to perform certain transactions in conjunction with the XFS manager 104. The service provider 106 is configured to correspond to the device 108 to be controlled, and receives the commands defined in the XFS protocol from the application 102 to drive the device 108. In other words, the service provider 106 is to control the device 108 according to the rules defined in XFS.

A plurality of devices 108 are provided that are driven by the service provider 106. The device 108 is mounted on the automation device 100 to perform individual operations, and refers to a keypad module, a printer module, a customer service module, a card reader module, a media recognition module, and the like.

The automation device 100 is equipped with a diagnostic platform (Diagnostic Platform) 110 for diagnosing a failure occurred during the operation of the device. That is, the diagnostic platform 110 diagnoses which part of the application 102, the XFS manager 104, the service provider 106, and the device 108 has occurred.

The configuration of this diagnostic platform 110 will be described in detail.

The diagnostic platform 110 includes first to fourth diagnostic units 112 and 114 for performing diagnosis on the application 102, the XFS manager 104, the service provider 106, and the device 108, respectively. 116, 118. In particular, the fourth diagnosis unit 118 that performs fault diagnosis on the device 108 is provided to directly use a firmware command of each device 108. This is for the device 108 to diagnose a physical failure or a failure that cannot be identified by the service provider 106 controlling the driving of the device 108.

Failure diagnosis on the application 102, XFS manager 104, service provider 106, and device 108 is made at the request of an administrator. That is, the first to fourth diagnosis units 112, 114, 116, and 118 are performed by a manager who directly checks the occurrence of a failure of the automation device 100 by requesting a failure diagnosis. The failure of the automation device 100 may be confirmed through a touch screen or a speaker of the automation device 100.

Request unit for requesting a fault diagnosis in the main body of the automation device 100 so that an administrator can request a fault diagnosis for performing the functions of the first to fourth diagnosis unit 112, 114, 116, 118. 120 is configured. The request unit 120 may be formed in the shape of a key button on the outer surface of the main body of the automation device (100). Alternatively, a touch button for the fault diagnosis request may be formed on the touch screen of the automated device 100. The touch screen displays a transaction menu screen for a predetermined transaction in the normal operation state of the automation device 100. On the other hand, if a failure occurs, the touch button for the failure diagnosis request is further displayed on the transaction menu screen, or the transaction menu screen is deleted and the touch button for the failure diagnosis request may be displayed.

When the key or touch button is operated, fault diagnosis of the application 102, the XFS manager 104, the service provider 106, and the device 108 proceeds. Each of these 102, 104, 106, 108 will be referred to as a unit. Fault diagnosis does not proceed simultaneously with the application 102, XFS manager 104, service provider 108, and device 108, and after diagnosing one unit is performed, diagnosing the next unit. This is done. And the fault diagnosis order for the unit is variable. That is, failure diagnosis is not always performed in any one order. This fault diagnosis order can be determined by order setting.

On the other hand, the first memory 130 is configured to store the failure diagnosis results of the first to fourth diagnostic unit 112, 114, 116, 118. In addition, in the failure diagnosis operation of the XFS manager 104, a second memory 140, which is a diagnostic DB for storing a failure diagnosis method of the XFS manager 104, is configured. In addition, a third memory 150 is provided for storing an XFS command within a predetermined time period before a failure time of the XFS command for executing the diagnosis of the service provider 106 in the unit. The first to third memories 130, 140, and 150 may use an existing memory installed in the automation device 100, or may be additionally provided. In addition, the above functions may be provided to each of three memories, or area allocation may be performed in one memory. Here, the first memory 130 and the third memory 150 are queue memories having a FIFO (First In First Out) structure.

After failure diagnosis of the first to fourth diagnosis units 112, 114, 116, and 118 is completed, the display unit 160 displaying failure information stored in the first memory 130 is configured. The display unit 160 serves to inform the administrator of which unit of the application 102, the XFS manager 104, the service provider 106, and the device 108 has failed. The display unit 160 may use a touch screen or form LEDs for each unit in the main body of the automation device 100.

The XFS-based automation device 100 configured as described above, the application 102, the XFS manager 104, the service provider 106, the device 108 receives the XFS command in order to operate, and the resulting information It has a structure that delivers to the application (102).

For example, when a predetermined transaction occurs in the automation device 100, the application 102 delivers the corresponding XFS command to the XFS manager 104 in the manner defined in the CEN / XFS standard.

The XFS manager 104 forwards the XFS command to the corresponding service provider 106 to perform the predetermined transaction that occurred.

The service provider 106 controls the corresponding device 108 to be driven by the XFS command, and the device 108 is operated by the XFS command.

The driving result of the device 108 is transmitted back to the application 102 through the service provider 106, the XFS manager 104.

By this process, the XFS-based automation device 100 performs a predetermined transaction normally.

However, if a failure occurs during the operation of the automation device 100 composed of a plurality of different manufacturers manufacturers, the cause of the failure must be identified and recovered as soon as possible. To this end, in the event of a failure, the administrator should request a failure diagnosis for the automation device 100 through the diagnostic platform 110, and the active response is to be made according to the result of the failure diagnosis.

In FIG. 1, the diagnostic paths of the units 102, 104, 106, and 108 are shown in the diagnosis of the failure. A and B are diagnostic paths for the application 102, C is a diagnostic path for the XFS manager, D is a diagnostic path for the service provider, and D is a diagnostic path for the device.

The diagnostic method for each unit 102, 104, 106, 108 via this diagnostic path is described in detail below.

Hereinafter, a failure diagnosis method of an automated device having a self-diagnosis function of the present invention will be described with reference to the accompanying drawings.

Failure diagnosis is performed by the diagnosis platform by the administrator who has confirmed the failure, and the failure diagnosis process for the application, the XFS manager, the service provider, and the device will be described separately.

2A and 2B are flowcharts illustrating a failure diagnosis process for an application of an automation device according to an exemplary embodiment of the present invention.

One. application  Diagnostic method.

The diagnostic method for the application provides two ways.

First way. This is referred to FIG. 2A.

First, the administrator who checks the failure requests the failure diagnosis for the automation device 100 through the request unit 120 (s102).

Then, the first diagnosis unit 112 of the diagnostic platform 110 modifies the window registry value for connection with the application 102 (s104). That is, although the path of the application-XFS manager-service provider is formed to perform a predetermined transaction until a diagnosis request occurs, the registry value is modified to change the path. The first diagnosis unit 112 backs up the original registry value when the failure diagnosis request is generated, and the application 102-XFS manager 104-first diagnosis unit 112 corrects the registry value. Path ('A') is set (S106). Therefore, when the modification of the registry value is completed, the path connected to the application 102-XFS manager 104-service provider 106 is blocked, and the application 102-XFS manager 104-first diagnosis unit ( A new route to 112 is created.

When a new path to the application 102-the XFS manager 104-the first diagnosis unit 112 is generated, an XFS command for diagnosing a fault is generated through the XFS manager 104 in the application 102. 1 is delivered to the diagnosis unit 112 (s108).

In this case, the XFS command transmitted to the first diagnosis unit 112 is divided into normal and abnormal states, and the first diagnosis unit 112 determines the failure by verifying the XFS command (S110). That is, the commands used in XFS-based are defined in the CEN / XFS international standard, and error codes for various failures are defined in these CEN / XFS. Accordingly, if a failure occurs in the application 102, an error code is generated in the application 102, and the first diagnosis unit 112 receiving the error code may diagnose the failure of the application 102. .

When it is determined that there is a failure in the application 102, the first diagnosis unit 112 stores the failure occurrence information in the first memory 130 (s112).

Thereafter, when the first diagnosis unit 112 completes the diagnosis of the failure of the application 102 (s114), the first diagnosis unit 112 restores the registry value to its original state (s116). On the other hand, the completion of the failure diagnosis is a time when the XFS command is not delivered to the application (102).

The second way. This is referred to FIG. 2B.

The first diagnosis unit 112 sets a message transmission / reception timeout value (S120).

In this state, when the failure diagnosis request occurs (s122), the first diagnosis unit 112 transmits a status confirmation message to the application 102 ('B' path) (s124). The status confirmation message refers to a message for asking whether the application 102 is in a normal or abnormal state.

After transmitting the status check message, the first diagnosis unit 112 checks whether there is a response to the status check message in the application 102 within the timeout value (S126). As a result, if there is a response within the timeout value, the first diagnosis unit 112 determines that the application 102 is currently in a normal state (S130). On the other hand, if there is no response within the timeout value, it is determined that there is a failure (s127). If there is no response, this may include a system crash due to an error of the application 102, or an infinite standby state.

If it is determined that there is a failure, the first diagnosis unit 112 stores the failure occurrence information in the first memory 130 (S128).

2. XFS  Manager diagnosis method.

See FIG. 3 for a diagnosis method of the XFS manager 104. 3 is a flowchart illustrating a failure diagnosis of the XFS manager according to an embodiment of the present invention.

First, the XFS manager 104 is a DLL capable of transferring XFS protocol between the application 102 and the service provider 106. As a result, the failure rate is relatively low compared to the application 102, the service provider 104, and the device 108.

However, an error code that is not defined in the application 102 and the service provider 106 is delivered, or there is an error in the window registry value referenced by the XFS manager 104, or the application 102 and the service provider 106 are used. There is always a possibility of failure due to a cause such as an error in the version of).

Thus, in order to diagnose the XFS manager 104, in preparation for a case where a failure can occur as described above, a diagnosis method for diagnosing the failure is stored in the second memory 140 in advance (S140). Of course, when a failure cause for the XFS manager 104 is added, a diagnosis method for diagnosing the added cause of failure may also be updated and stored in the second memory 140.

In such a state, when a diagnosis request for the XFS manager 104 occurs (s142), the second diagnosis unit 114 refers to a diagnosis method stored in the second memory 140, and the XFS manager ( Perform a diagnosis of the failure (104) ('C' path) (s144).

If it is determined that the failure diagnosis result (s146), the XFS manager 104 is abnormal, the failure information about it is stored in the first memory 130 (s148).

Here, the second diagnosis unit 114 preferably performs a failure diagnosis by all the diagnosis methods stored in the second memory 140.

3 . How to diagnose service provider .

This is referred to FIG. 4. 4 is a flowchart illustrating a failure diagnosis of a service provider according to an embodiment of the present invention.

In order to diagnose the failure of the service provider 106, an operation of storing the contents of the XFS command transmitted to the application 102-the XFS manager 104-the service provider 106 in the third memory 150 is required. . This is to confirm whether the service provider 106 operates normally according to the XFS command executed by the application 102.

The operation of storing the XFS command contents in the third memory 150 is performed when the automation device 100 is normally driven. Thus, when the automation device 100 fails, XFS commands within a predetermined time before the failure occurs are sequentially stored in the third memory 150. This is possible because the third memory 150 has a FIFO structure.

As such, when the automation device 100 is normally driven and the operation of continuously storing and deleting the XFS command in the third memory 150 is performed (s150), when the failure occurs in the automation device 100, the failure occurs. A diagnosis request is generated (s152). A plurality of XFS commands are stored in the third memory 150 when a failure diagnosis request occurs. In this case, it is assumed that the media withdrawal command and the card information read command are stored.

When the failure request occurs, the third diagnosis unit 116 accesses a media withdrawal command among the XFS commands stored in the third memory 150, and provides a service provider related to the media withdrawal through the XFS manager 104. And transmits it to (106) (path D) (s154).

The service provider 106 transmits a media withdrawal command to the media withdrawal module connected to the service provider 106, and receives a driving result value from the media withdrawal module (s156). In this case, the driving result value is a value for whether the medium withdrawal module is normally driven so that the medium can be withdrawn normally.

The service provider 106 transmits the driving result value to the third diagnosis unit 116 (S158).

The third diagnosis unit 116 determines whether the service provider 106 has a failure according to the driving result value (S160). In the failure determination, the media withdrawal command is transmitted to the service provider 106 related to the media withdrawal, but it is determined that the failure occurs when a different result is received. That is, due to the failure of the service provider 106, the XFS command was not normally executed.

When the third diagnosis unit 116 determines that a failure occurs in the service provider 106 related to the media withdrawal (s162), the third diagnosis unit 116 stores the failure occurrence information in the first memory 130 (s164). When the failure diagnosis for the medium withdrawal command is completed, the medium withdrawal command is deleted from the third memory 150.

The third diagnosis unit 116 checks the third memory 150 when the failure diagnosis of the service provider 106 related to the withdrawal of the medium is completed (S166).

As a result of the check, if another XFS command is stored in the third memory 150 (that is, the card information read command), the process proceeds to step 154 to perform a failure diagnosis on the service provider 106 related thereto. In the failure diagnosis associated with the card information read command, the third diagnosis unit 116 checks the driving result value performed by the XFS command transmitted to the service provider 106 and determines whether there is a failure. If a failure occurs, the failure information is stored in the first memory 130.

The third diagnosis unit 116 checks whether an XFS command is further stored in the third memory 150. If another XFS command is further stored, the above operation is repeatedly performed.

The failure diagnosis of the service provider 106 continues until all of the failure diagnosis of the service provider 106 is completed by the XFS instruction stored in the third memory 150.

4 . Device diagnostic method.

This is referred to FIG. 5. 5 is a flowchart illustrating a failure diagnosis of a device according to an embodiment of the present invention.

Diagnosis of the device 108 requires that the fourth diagnosis unit 118 directly control the device 108 without diagnosing the failure without passing through the XFS manager 104. This is because the XFS command has a limited range of direct control of the device 108.

Accordingly, the fourth diagnostic unit 118 is provided in the form of a device library, and directly uses the firmware command of each device 108. Since the device 108 is diagnosed for each fault, when the devices 108 are manufactured by different manufacturers, the fourth diagnosis unit 118 must also be provided to correspond to the device 108.

The failure diagnosis for the device 108 may be performed when the failure diagnosis request is generated (S170). The service provider 106 may be connected to the application 102 with respect to the device 108 to be tested by the fourth diagnosis unit 118. ) Requests to be in a close state (s172). The closed state of the service provider 106 is a state in which communication with the device 108 connected to it is terminated.

When the closed state is requested, the application 102 makes a close request to the service provider 106 through the XFS manager 104. Then, the service provider 106 terminates the communication with the corresponding device 108 connected with it, and transmits the communication termination result to the application 102 and the fourth diagnosis unit 118 (s174).

Accordingly, the fourth diagnosis unit 118 may recognize that communication between the device 108 to be tested and the corresponding service provider 106 is terminated.

Thereafter, the fourth diagnosis unit 118 directly connects to the device 108 to be tested ('E' path) (s176) and starts a failure diagnosis process (s178). The fourth diagnosis unit 118 performs a failure diagnosis on the predetermined device 108 and receives the result of the execution.

The fourth diagnosis unit 118 determines whether the corresponding device 108 has a failure according to the result of the execution (S180). The failure determination determines whether the device 108 operates abnormally, such as when the device 108 is not actually driven.

Thus, when the corresponding device 108 is in an abnormal driving state, the fourth diagnosis unit 118 determines that a failure has occurred, and stores the failure information on the tested device 108 in the first memory 130 ( s182).

On the other hand, the diagnostic platform 110 is a failure diagnosis performed by the first to fourth diagnostic unit 112, 114, 116, 118 for the unit 102, 104, 106, 108 When this is completed, the diagnostic result stored in the first memory 130 is displayed through the display unit 160.

Accordingly, if the failure information of the application 102 is in the first memory 130, the application failure is displayed on the display unit 160. If the failure information of the XFS manager 104 is in the first memory 130, the XFS manager is displayed. Display the failure on the display unit 160, and if the failure information of the service provider 106 is in the first memory 130, displays the service provider failure on the display unit 160, the failure information of the device 108 Is in the first memory 130, a device failure is displayed on the display unit 160.

In this failure indication, in particular, since the service provider 106 and the device 108 are configured in plural numbers, the service provider 106 and the device 108 individually indicate which service provider and the device have a failure. In addition, if all of the units 102, 104, 106 and 108 are faulty, it indicates that all units are faulty.

In this embodiment, when a failure occurs in the automation device, the administrator diagnoses the failure of the application, the XFS manager, the service provider, and the device at the same time with a single button operation. However, failure diagnosis may be performed separately for each of the application, the XFS manager, the service provider, and the device. This is possible by providing a plurality of failure diagnosis request keys per unit. This can be usefully used to identify a failure for a unit that is primarily suspected at the time of failure.

On the other hand, the automation device of the present embodiment may be a financial automation device. In this case, in the case of the automated teller machine manufactured by several units, the cause of the occurrence of a failure can be quickly identified and restored, thereby reducing the time for which the financial transaction due to the failure is stopped as much as possible.

While the present invention has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the invention is not limited to the disclosed embodiments. In other words, within the scope of the present invention, all of the components may be selectively operated in combination with one or more. In addition, although all of the components may be implemented as one independent hardware, some or all of the components may be selectively combined to perform a part or all of the functions in one or a plurality of hardware. As shown in FIG. Codes and code segments constituting the computer program may be easily inferred by those skilled in the art. Such a computer program may be stored in a computer readable storage medium and read and executed by a computer, thereby implementing embodiments of the present invention. As the storage medium of the computer program, a magnetic recording medium, an optical recording medium, a carrier wave medium, or the like may be included.

Furthermore, the terms "comprises", "comprising", or "having" described above mean that a component can be implanted unless otherwise specifically stated, But should be construed as including other elements. All terms, including technical and scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs, unless otherwise defined. Terms used generally, such as terms defined in a dictionary, should be interpreted to coincide with the contextual meaning of the related art, and shall not be interpreted in an ideal or excessively formal sense unless explicitly defined in the present invention.

The foregoing description is merely illustrative of the technical idea of the present invention, and various changes and modifications may be made by those skilled in the art without departing from the essential characteristics of the present invention. Therefore, the embodiments disclosed in the present invention are intended to illustrate rather than limit the scope of the present invention, and the scope of the technical idea of the present invention is not limited by these embodiments. The protection scope of the present invention should be interpreted by the following claims, and all technical ideas within the equivalent scope should be interpreted as being included in the scope of the present invention.

100: automation device 102: application (AP)
104: XFS Manager 106: Service Provider (SP)
108: device 110: diagnostic platform
120: request unit 160: display unit
112 to 118: first to fourth diagnostic units
130 to 160: first to third memory

Claims (9)

An application (AP) for operating the automation device;
A plurality of service providers receiving commands from the AP and driving the plurality of devices, respectively;
An XFS manager connecting the application and a service provider;
A request unit for requesting a failure diagnosis for the application, the service provider, the XFS manager, and the device when the failure of the automation device occurs;
A diagnostic platform for separately diagnosing failure of the application, service provider, XFS manager, and device by the request unit; And
A display unit for displaying a diagnosis result of the diagnosis platform,
The diagnostic platform may include a first diagnostic unit for diagnosing the application;
A second diagnostic unit for diagnosing the service provider;
A third diagnostic unit for diagnosing the XFS manager,
Automation device having a self-diagnostic function comprising a fourth diagnostic unit for diagnosing the device. The method of claim 1,
A first memory for storing a diagnosis result of the first to fourth diagnosis units of the diagnosis platform;
A second memory for storing a diagnostic scheme for the XFS manager;
And a third memory configured to store an XFS command within a predetermined time before a failure time of the automated device occurs when executing the diagnosis of the service provider. The method of claim 2, wherein the first diagnostic unit,
Diagnosing the failure of an application by XFS command transmitted from the application in connection with the application and the XFS manager through the modification of a registry value, or sending a message to the application and transmitting the message within a predetermined timeout. The automatic device having a self-diagnosis function, characterized in that for checking the response of the message, to diagnose the failure of the application. The method of claim 2, wherein the second diagnostic unit,
Automated device having a self-diagnosis function, characterized in that for diagnosing the failure of the XFS manager with reference to the diagnostic method stored in the second memory. The method of claim 2, wherein the third diagnostic unit,
The failure of the service provider is diagnosed using the XFS command stored in the third memory, and the failure diagnosis is repeatedly performed until all the XFS commands stored in the third memory are deleted. Automated instrument with diagnostic function. The method of claim 2, wherein the fourth diagnostic unit,
Automated device having a self-diagnosis function, characterized in that for diagnosing the failure using the firmware command of the device directly in the state of direct connection with the device. Generating a failure diagnosis request when a failure of the automated device occurs;
A diagnostic platform performing a failure diagnosis on an application, an XFS manager, a service provider, and a device of the automation device according to the failure diagnosis request and storing a failure diagnosis result; And
The diagnostic platform providing the stored diagnostics results;
The diagnostic platform, the diagnostic platform, the first diagnostic unit for diagnosing the application,
A second diagnostic unit for diagnosing the service provider;
A third diagnostic unit for diagnosing the XFS manager,
And a fourth diagnosis part for diagnosing the device. The method of claim 7, wherein
The fault diagnosis result, the fault diagnosis method of the automated device, characterized in that provided after the failure diagnosis for the application, the XFS manager, the service provider and the device all at once. The method of claim 8,
The fault diagnosis result is provided only when a fault diagnosis item is stored in a memory.

Images