JP2012234253A - Portable terminal and failure detection system thereof - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a portable terminal and a failure detection system thereof capable of promptly specifying a cause of a shock at the time of the breakdown of the portable terminal.SOLUTION: A failure detection system includes in a portable terminal an acceleration sensor and a shock database for storing a shock pattern that is a time change of acceleration at the time of reception of a shock or oscillation. When a time change of acceleration detected by the acceleration sensor matches the shock pattern, a warning on the handling is displayed on the portable terminal. The shock database may be installed in a server connected to the portable terminal through a network. The server checks the time change of acceleration transmitted from the portable terminal with the shock pattern and, when they match each other, issues a warning to the portable terminal as necessary. When a different portable terminal detects a time change of acceleration that matches a similar shock pattern, the server may issue a warning to all portable terminals in the same environment.

Description

  The present invention relates to a portable terminal and a failure detection system for the portable terminal.

  Today, POS (Point Of Sale) systems are widely used in stores that sell products. However, in department stores and specialty stores, the number of products to be purchased is often from one to several. In such a case, the travel time and the waiting time at the POS counter are shortened and the convenience for the customer is improved when the goods are settled at the place where the goods are sold rather than the goods are brought to the POS counter and settled. For that purpose, it is necessary to make it possible for the clerk to carry a tool for making a payment. For such applications, there is a system called mobile POS. The store clerk has a portable terminal equipped with a tool necessary for payment such as a card reader or a barcode reader, and makes payment using the portable terminal at the place where the product is sold.

  When using such a mobile POS system, a lot of similar mobile terminals are arranged in one store, and the mobile terminal communicates with a server arranged in the store to perform settlement processing. Such a mobile terminal is handled by many shop assistants while selling products in the store, so the mobile terminal tends to be dropped or hit against a wall. If a strong impact is applied to the mobile terminal, it may cause a failure, but if a plurality of shop assistants handle the mobile terminal carelessly, a similar failure occurs. A means for preventing the occurrence of such a failure is desired.

  When the mobile terminal falls, the mobile terminal is sent out for repair. At the time of repair, the drop direction and impact force analysis can be performed from the damaged state of the mold cover and the substrate, and the amount of distortion of the sheet metal member can be analyzed. Failure analysis such as drop direction and impact force analysis is performed.

However, since such failure analysis is often difficult, it is conceivable to provide an acceleration sensor in the portable terminal and record the situation when the failure occurs.
Various acceleration sensor technologies in conventional portable devices are already known. For example, in a hard disk drive (HDD) or the like, it is known to detect a fall (weightlessness) and to retreat a fixed area of a magnetic head of the HDD. As another application of the acceleration sensor, there is one that detects an attempt to destroy the apparatus by detecting an impact or high acceleration in a tamper-resistant high security apparatus. Furthermore, in order to prevent camera shake, it is also known that a vibration is detected by an acceleration sensor, or a game controller performs movement, direction detection, terminal up / down detection, and the like.

  Other conventional techniques for failure analysis using acceleration sensors include those that detect the degree of impact by using acceleration and time changes at the time of impact, and those that record the acceleration at the time of impact of the terminal and identify fall failures. is there.

JP 2009-162703 A JP 2008-232631 A JP 2009-053949 A JP-A-2005-241331

However, conventionally, the following problems have occurred.
・ Even if the device returned to failure is examined, detailed information such as the location, direction, and frequency of the drop impact is not recorded. It takes time.
・ Fatigue caused by the accumulation of small impacts hardly left traces on the appearance, and the cause of failure could not be determined.
・ In large-scale operation, even if problems occurred on multiple terminals, real-time improvement measures could not be taken.

  The subject of this invention is providing the portable terminal which can identify the cause of the impact at the time of failure of a portable terminal rapidly, and its failure detection system.

  A mobile terminal according to one aspect of the present invention includes a display unit that displays a message, an acceleration sensor that detects a time change in acceleration at the time of impact, vibration, or dropping, and a pattern of time change in acceleration under a predetermined situation Is stored as an impact pattern, and a control unit that displays a warning message on the display unit when the time change of the acceleration detected by the acceleration sensor matches the impact pattern of the impact database.

  A fault detection system according to an aspect of the present invention is a fault detection system that detects a situation in which a fault occurs by communicating with a mobile terminal, and includes a display unit that displays a message, and an acceleration during impact, vibration, or fall. A time-dependent change in acceleration detected by the acceleration sensor, a mobile terminal equipped with an acceleration sensor that detects the time change of the time, a shock database that stores a time-change pattern of acceleration under a predetermined condition as an impact pattern, A server connected to the mobile terminal via a network, which displays a warning message on the display unit of the mobile terminal when it matches an impact pattern in the impact database;

  ADVANTAGE OF THE INVENTION According to this invention, the system which detects the cause of the impact at the time of the failure of a portable terminal rapidly, and the fault in real time, and displays a warning on a portable terminal can be provided.

It is a functional block block diagram of the stand-alone type | mold portable terminal according to this embodiment. It is a system configuration figure of a server connection type failure detection system according to this embodiment. It is a functional block block diagram of a server connection type failure detection system. It is a figure which shows the example of the data stored in impact DB. It is an external view of a portable terminal. It is a flowchart of an impact detection process. It is a server type | system | group failure detection system according to this embodiment, Comprising: It is a system configuration | structure figure of a structure which transmits a warning message simultaneously to a some portable terminal from a server. It is a functional block block diagram of the server type | mold failure detection system of the structural example of FIG. It is the figure which showed the example of the data stored in a server memory. It is a flowchart of the operation | movement of the server in the structural example of FIG. It is a flowchart of the process which produces the data of the impact pattern of impact DB in advance. It is a flowchart of the process which produces the data of impact DB in real time in a server type failure detection system. It is a server type | mold failure detection system according to this embodiment, Comprising: It is a flowchart of the creation process of impact DB in case a server is provided with impact DB. It is a figure explaining the format of impact data. It is a flowchart of the pattern matching process of an impact pattern.

In the present embodiment, the following configuration is provided.
(1) -1 Drop the mobile terminal from various directions and heights in advance, give impact and vibration, and store the acceleration and its change over time in a database as an impact pattern (impact DB).
(1) -2 The above impact DB is mounted on a portable terminal or server, the acceleration of the terminal is recorded, and compared with the impact DB, the cause of the impact at the time of a drop failure is quickly identified.
(2) The impact detection information of a plurality of terminals is collected on a server, and when a plurality of occurrences of the same failure are observed, an improvement instruction is issued to all terminals in real time to prevent the failure.

As described above, the cause of the impact at the time of failure of the mobile terminal is quickly identified.
In the conventional impact analysis, it took several hours to identify the cause of the impact by examining the appearance of the failure generating device. However, according to the present embodiment, the cause of the impact is identified in real time by comparing the patterns of the impact DB. It becomes possible.

Also, troubles caused by accumulation of small vibrations or small impacts that could not be detected in the past can be quickly identified by registering vibration patterns in the impact DB.
In addition, in the operation of a plurality of portable terminals, it becomes possible to prevent failure in real time.

  Conventionally, after multiple faulty terminals with the same tendency are returned to the repair center, the cause is analyzed and an operation improvement instruction is given in several days. Alone or server analysis can display real-time alerts when failures occur.

FIG. 1 is a functional block configuration diagram of a stand-alone portable terminal according to the present embodiment.
The stand-alone portable terminal 9 of the present embodiment incorporates an impact DB 15. The memory 12 stores an OS for operating the mobile terminal 9 and the CPU 11 operates the mobile terminal 9 by executing the OS. The operation unit 13 receives an input from the user of the mobile terminal 9. Input from the operation unit 13 is processed by the CPU 11 and displayed on the display unit 10. The display unit 10 displays information generated in the product settlement process. The mobile terminal 9 is equipped with an acceleration sensor 14 and stores the detected acceleration and its change over time in the memory 12 as an impact pattern. The database (impact DB) 15 stores in advance as an impact pattern the acceleration when various impacts and vibrations are applied as a test when the mobile terminal 9 is designed and developed in advance.

  The CPU 11 determines whether or not the impact pattern detected by the acceleration sensor 14 stored in the memory 12 matches the impact pattern in the impact DB 15. If there is a match, the CPU 11 sets the impact pattern in the impact DB 15. A corresponding warning message is read out and a warning display is displayed on the display unit 10.

  The above is the configuration of the stand-alone mobile terminal, but it is also possible to configure a failure detection system in a form in which the mobile terminal is connected to a server via a network.

FIG. 2 is a system configuration diagram of a server connection type failure detection system according to the present embodiment.
Each clerk holds one portable terminal 20. The mobile terminal 20 accesses the server 21 connected to the network 26 via the access point 25. In this case, the impact DB 15 is provided in the mobile terminal 20 or the server 21. Here, the shock DB 15 will be described as being provided in the server 21. The mobile terminal 20 transmits the impact pattern detected by the built-in acceleration sensor to the server 21, and the server 21 collates the detected impact pattern with the impact pattern stored in the impact DB.

  For example, in the case of a mobile POS system, the server 21 is arranged in a store or a management center of the mobile POS system.

FIG. 3 is a functional block configuration diagram of the server connection type failure detection system.
3, the same components as those in FIG. 1 are denoted by the same reference numerals, and description thereof is omitted.
The mobile terminal 20 does not include the impact DB 15 but includes a communication unit 22 instead. The communication unit 22 accesses the server 21 via the network. The server 21 communicates with the mobile terminal 20 using the communication unit 23. The server 21 receives the detected impact pattern sent from the mobile terminal 20, compares it with the impact pattern in the impact DB 15, and detects whether there is a match. The server 21 is monitored by the operator, and when the impact pattern sent from the portable terminal 20 matches the impact pattern in the impact DB 15, the server 21 displays that fact.

  From the contents displayed by the server 21, the operator determines whether or not to issue a warning to the portable terminal 20 that has seen the coincidence of the impact pattern. When issuing a warning, a warning message is sent to the portable terminal 20 to display a warning display on the display unit 10.

  In FIG. 3, the impact DB 15 is provided in the server 21, but may be received by the mobile terminal 20. Then, the mobile terminal 20 may collate the impact pattern, and if they match, the server 21 may be notified together with the impact pattern.

FIG. 4 is a diagram illustrating an example of data stored in the impact DB.
The impact DB stores data in which an impact pattern and a drop / vibration condition when the impact pattern is obtained are associated with a warning message. The drop / vibration condition describes what acceleration and vibration are applied to the mobile terminal. Under such a fall / vibration condition, the impact pattern detected by the acceleration sensor is stored in association with each other. The impact pattern is the acceleration in the x, y, and z axis directions with respect to the portable terminal and the change with time. When such an impact pattern is received, a warning message for urging the user to handle it is stored.

  For example, no. Since the impact pattern No. 1 was obtained from a height of 1.5 m and dropped with the LCD screen down, a warning message “Do not bring it to a high place” is registered. No. Since the impact pattern No. 2 was obtained from a height of 1.2 m in a state where the LCD screen was dropped, a warning message “attach strap” is registered. This is because the fall from 1.5 m can be assumed to be placed at a high place, and the fall from 1.2 m can be assumed to have fallen from the user's hand.

  No. The impact pattern 3 is a case where a mobile terminal is mounted on a truck and runs on a gravel road, and the mobile terminal is placed sideways. In this case, since the mobile terminal is not properly attached to the cradle and vibration may occur, a warning message “confirm cradle attachment” is registered. No. The impact pattern 4 is a case where a portable terminal is mounted on a truck and runs on a gravel road, and the portable terminal is placed vertically. In this case, since there is a possibility that the position where the portable terminal is attached to the cradle may be incorrect, a warning message “The cradle position is incorrect” is registered.

  As another example, when the battery case portion is hit with 1.3N, a warning message “Please operate carefully” is registered. Such an impact pattern is generated because there is a high possibility that the portable terminal has hit something.

  The warning message as described above, when registering an impact pattern, registers a message that is considered appropriate by an operator assuming the actual situation of the mobile terminal assumed from the drop / vibration conditions.

FIG. 5 is an external view of the mobile terminal.
The main body of the mobile terminal 30 has a display screen 32 and an input key 33 arranged on the front surface, and a card reader, a barcode reader, etc., which are not shown, are arranged on the back surface. The cradle 31 is a housing that holds the mobile terminal 30 and stores the mobile terminal 30 attached to the cradle 31 when the mobile terminal 30 is not used. The cradle 31 may have a charging function in addition to holding the mobile terminal 30.

FIG. 6 is a flowchart of the impact detection process.
When the impact detection is started, the current acceleration value is collected in step S10. In step S11, the acceleration value is written in the memory. In step S12, the impact pattern including the past X times (X is determined by the designer as appropriate) includes an acceleration vector (an acceleration value composed of a set of x, y, and z components is called an acceleration vector). And the impact pattern of the impact DB are pattern matched. In step S13, it is determined whether there is a matching pattern. If the determination in step S13 is No, the process returns to step S10, and if the determination in step S13 is Yes, the process proceeds to step S14. In step S14, the warning message of the matched impact pattern stored in the impact DB is displayed on the portable terminal, and the process ends.

FIG. 7 is a system configuration diagram of a server type failure detection system according to the present embodiment, in which a warning message is sent simultaneously from a server to a plurality of portable terminals.
In this configuration example, the mobile terminal 20 accesses the access point 25 and transmits an impact pattern to the server 21 via the network 26. The server 21 compares the received impact pattern with the impact pattern of the built-in impact DB and determines whether they match. If they match, the impact pattern from which mobile terminal matches with which impact pattern in the impact DB within a predetermined time is stored in the memory. For example, if the impact pattern from different mobile terminals matches the same impact pattern in the impact DB a predetermined number of times, it is determined that such a situation can occur in other mobile terminals, and all mobile terminals are Display a warning message. By doing in this way, it is possible to quickly detect a situation in which a failure that tends to occur in many portable terminals is detected, send a warning to all portable terminals, and prevent the occurrence of the failure.

FIG. 8 is a functional block configuration diagram of the server type failure detection system of the configuration example of FIG.
In FIG. 8, the same components as those in FIG. 3 are denoted by the same reference numerals, and description thereof is omitted.

  In FIG. 8, the server 21 is provided with a memory 40 (server memory). The memory 40 stores a pattern matching result between the impact pattern sent from the mobile terminal 20 and the impact pattern of the impact DB 15. As a result of pattern matching, when the impact patterns from different mobile terminals coincide with the impact pattern in the impact DB 15 a predetermined number of times within a predetermined time, the same situation occurs in all mobile terminals and a similar failure occurs. Judgment is likely to occur. And when judged so, a warning message is displayed on all the portable terminals.

FIG. 9 is a diagram illustrating an example of data stored in the server memory.
The server memory data includes the impact pattern occurrence time, the identifier of the mobile terminal that transmitted the impact pattern, the identifier of the matched impact pattern, the number of matches, and whether all mobile terminals have been warned. Information is stored in association with each other.

  In FIG. 9, the impact pattern from terminal D is the impact No. 165. Impact No. 165 is the same as the impact pattern from the terminal C. When the impact pattern is received from the terminal D, the number of times that the same impact pattern is matched at different terminals is two. In this case, since the same impact pattern is generated in different terminals, it can be determined that the same impact pattern is likely to be generated in other terminals. Therefore, when an impact pattern is received from the terminal D, a warning message is transmitted to all terminals, and a warning display is performed on the display screens of all terminals.

Here, two times are exemplified as the predetermined number of times within the predetermined time when the coincidence is detected, but this number should be appropriately set by the designer.
With the above processing, the user can be warned in advance so as to avoid the situation where a similar failure occurs in a plurality of portable terminals, so that it is possible to prevent a plurality of portable terminals from malfunctioning due to the same cause. I can do it.

FIG. 10 is a flowchart of the operation of the server in the configuration example of FIG.
In step S20, shock pattern data is received from the portable terminal. This data is written in the server memory in step S21. In step S22, it is searched whether or not there is the same pattern in all the past or in the designated time. Here, the search for the same pattern is performed only for the impact pattern within the past designated time because the operation may be already improved so as not to cause a problem even if a similar impact pattern occurs. The designated time is set by the operator in consideration of one week, one month, the turnover rate of store sales, and the like.

  In step S23, it is determined whether or not the same pattern is found in the search in step S22. If the determination in step S23 is No, the process returns to step S20. If the determination in step S23 is yes, in step S24, a warning message is transmitted to all terminals and displayed, and the process ends.

FIG. 11 is a flowchart of processing for creating impact pattern data in the impact DB in advance.
When the creation of the impact pattern is started, the current time and acceleration are stored as a final record in step S30. In step S31, when an impact occurs, it is determined whether or not it is within the acceleration measurement period. If the determination in step S31 is Yes, in step S32, the difference between the acceleration of the final recording recorded in step S30 and the current acceleration is compared, and in step S33, it is determined whether or not the difference exceeds a threshold value. to decide. This threshold value is used to remove measurement errors and unacceptable changes in acceleration. The designer determines the threshold value in advance. If the determination in step S33 is No, the process returns to step S31. If the determination in step S33 is Yes, in step S34, the final recording, the current time difference, and acceleration are added to the memory as a set. In step S35, the current time and acceleration are stored as the final record, and the process returns to step S31.

  If the determination in step S31 is No, in step S36, all sets of data added from the start to the end of measurement are recorded in the impact DB as an impact pattern, and the process ends.

Since the above process is a process of creating one impact pattern, the impact pattern of the impact DB is accumulated by repeating this for various drop / vibration conditions.
The above processing is for previously storing impact pattern data in the impact DB, but it is also possible to sequentially store impact patterns in real time.

FIG. 12 is a flowchart of a process for creating shock DB data in real time in a server type failure detection system.
The process of FIG. 12 shows a case where the mobile terminal has a shock DB locally and stores the shock pattern in the local shock DB in real time.

  In step S40, the current time and acceleration are stored as the final record. In step S41, when an impact occurs, (current time)-(final recording time) is calculated and compared with a threshold value. If the calculated value is less than the threshold value in step S41, the difference between the acceleration of the final recording and the current acceleration is compared in step S42, and it is determined whether or not the difference exceeds the threshold value in step S43.

  If the determination in step S43 is no, the process returns to step S41. If the determination in step S43 is yes, in step S44, the final recording, the current time difference, and acceleration are added to the impact DB as one set. The threshold value in step S43 has the same meaning as in step S33 in FIG. In step S45, the current time and acceleration are stored as the final record, and the process returns to step S41.

  If it is determined in step S41 that the calculated value is greater than or equal to the threshold value, the process proceeds to step S46. This is determined to be equal to or greater than the threshold value of the time length of the impact pattern. That is, the threshold value of step S41 sets how much time acceleration is recorded by the impact pattern. This threshold is appropriately set by the designer.

  In step S46, the impact DB is searched using all sets of data added from the start of measurement to completion as impact patterns. In step S47, it is determined whether a similar pattern already exists. If the determination in step S47 is No, the impact pattern is recorded in the impact DB in step S48, and the process proceeds to step S49. If the determination in step S47 is yes, the process proceeds directly to step S49. In step S49, an impact pattern is notified to the server in order to notify the server that an impact has occurred.

FIG. 13 is a server type failure detection system according to the present embodiment, and is a flowchart of an impact DB creation process when the server includes an impact DB.
In the case of FIG. 13, the server is provided with an impact DB.

  In step S55, the current time and acceleration are received from the portable terminal and stored as the final record. In step S56, when an impact occurs, the current time and acceleration are received from the portable terminal. In step S57, (current time of portable terminal) − (final recording time of portable terminal) is calculated. If the calculated value in step S57 is less than the threshold value, the process proceeds to step S58. In step S58, the difference between the acceleration of the last recording and the current acceleration is compared. In step S59, it is determined whether or not the difference exceeds a threshold value. If the determination in step S59 is No, the process returns to step S56, and if the determination in step S59 is Yes, the process proceeds to step S60. The threshold value in step S59 is the same as that in step S43 in FIG.

  In step S60, the last recording, the current time difference, and acceleration are added to the memory as a set. In step S61, the current time and acceleration are stored as the final record, and the process returns to step S56. If it is determined in step S57 that the calculated value is equal to or greater than the threshold value of the impact pattern time length, the process proceeds to step S62. The threshold here is the same as in step S41 of FIG.

  In step S62, the data in the memory is searched using all sets of data added from the start to the end of the measurement as impact patterns. In step S63, it is determined whether there is already a similar pattern. If the determination in step S63 is yes, in step S64, the impact pattern is sent to the server, recorded in the impact DB, and the process ends. If the determination in step S63 is No, the process ends.

FIG. 14 is a diagram for explaining the format of impact data.
FIG. 14A shows a format of acceleration data. If any of the x, y, and z components of acceleration changes beyond the threshold value a, one record of the elapsed time from the previous transmission, x-direction acceleration value, y-direction acceleration value, and z-direction acceleration value Generate as data.

FIG. 14B shows an example of data when the device falls from the desk and bounces several times as an example.
When the device falls, it takes a considerable amount of time since the last impact, so the time from the previous transmission is “999999” as an example. At this time, a direction in which the acceleration value becomes 0 occurs due to falling. Thereafter, when the time from the previous transmission is “450” due to a drop impact, the x-direction acceleration value shows a large value. Thereafter, when the time from the previous transmission is “3”, the device jumps into the air and the x-direction acceleration value is “0”. When the time from the previous transmission is “91”, an impact occurs again and the y-direction acceleration value shows a large value. When the time from the previous transmission is “2”, the device jumps up again into the air, the y-direction acceleration value becomes “0”, and when the time from the previous transmission is “20”, the device is attached to the floor and is in the x direction. The acceleration value is a large value.

Here, the unit of time from the previous transmission is preferably a millisecond unit in order to detect a falling and jumping state or the like.
In the case of a server type failure detection system, when the mobile terminal is connected to the server, data in a format as shown in FIG. 14A is notified to the server in real time.

FIG. 15 is a flowchart of impact pattern pattern matching processing.
In FIG. 15, which pattern in the impact DB matches the generated impact pattern is determined by extracting a pattern having the highest similarity by pattern matching and determining whether the similarity of the pattern exceeds a threshold value.

  The pattern matching algorithm is a simple method, such as selecting a pattern that minimizes the sum of absolute values of time / acceleration value differences (which will be described later with negative similarity), DP (Dynamic Programming) matching, etc. The expansion / contraction matching method can be used.

  In step S70, the current maximum similarity is set to zero. In step S71, it is determined whether or not there is a remaining pattern in the impact DB. If the determination in step S71 is yes, the next pattern in the impact DB is read in step S72. In step S73, the similarity between the generated pattern and the impact pattern read from the impact DB is calculated. In step S74, it is determined whether the similarity is maximum. If the determination in step S74 is no, the process returns to step S71. If the determination in step S74 is yes, the maximum similarity value is updated with the current similarity in step S75, and the process returns to step S71.

  If the determination in step S71 is No, it is determined in step S76 whether the maximum similarity is greater than or equal to a threshold value. If the determination in step S76 is Yes, a similar impact pattern is detected in step S77. If the determination in step S76 is No, it is determined in step S78 that there is no similar impact pattern, and the process is performed. finish.

9, 20, 30 Mobile terminal 10, 32 Display unit 11 CPU
12, 40 Memory 13 Operation unit 14 Acceleration sensor 15 Impact database 21 Server 22, 23 Communication unit 25 Access point 26 Network 31 Cradle 33 Input key

Claims (8)

A display for displaying a message;
An acceleration sensor that detects temporal changes in acceleration during impact, vibration, or fall;
An impact database that stores a time-varying pattern of acceleration under a predetermined situation as an impact pattern;
A control unit that displays a warning message on the display unit when a time change in acceleration detected by the acceleration sensor matches an impact pattern in the impact database;
A portable terminal comprising: A failure detection system that detects a situation where a failure occurs by communicating with a mobile terminal,
A portable terminal comprising a display unit for displaying a message, and an acceleration sensor for detecting a temporal change in acceleration at the time of impact, vibration, or dropping;
An impact database that stores a temporal change pattern of acceleration under a predetermined situation as an impact pattern, and a warning message is displayed when the temporal change in acceleration detected by the acceleration sensor matches the impact pattern of the impact database. A server connected to the mobile terminal via a network, to be displayed on the display unit of the mobile terminal;
A failure detection system comprising:   The failure detection system according to claim 2, wherein the impact database is provided in the mobile terminal.   The failure detection system according to claim 2, wherein the impact database is provided in the server. The server is connected to a plurality of mobile terminals via a network,
When the time change of the acceleration detected by the acceleration sensor of a different mobile terminal matches the same impact pattern a predetermined number of times within a predetermined time, a warning message is sent to all of the plurality of mobile terminals connected to the server. The fault detection system according to claim 2, wherein the fault detection system is displayed.   The failure detection system according to claim 2, wherein the impact database is created in advance.   The failure detection system according to claim 2, wherein an entry is added to the impact database every time the mobile terminal newly detects a change in acceleration. A processing method of a failure detection system for detecting a situation where a failure occurs by communicating with a mobile terminal,
The time variation of acceleration under impact, vibration or drop detected by the acceleration sensor provided in the portable terminal is stored in the impact database, and the time variation pattern of acceleration under a predetermined situation is stored in the impact pattern. Compared to
When a time change in acceleration detected by the acceleration sensor matches an impact pattern in the impact database, a warning message is displayed on the display unit of the mobile terminal.
A processing method characterized by the above.