WO2019130469A1 - 保全設計支援システム - Google Patents

保全設計支援システム Download PDF

Info

Publication number
WO2019130469A1
WO2019130469A1 PCT/JP2017/046905 JP2017046905W WO2019130469A1 WO 2019130469 A1 WO2019130469 A1 WO 2019130469A1 JP 2017046905 W JP2017046905 W JP 2017046905W WO 2019130469 A1 WO2019130469 A1 WO 2019130469A1
Authority
WO
WIPO (PCT)
Prior art keywords
maintenance
support system
asset
design support
failure
Prior art date
Application number
PCT/JP2017/046905
Other languages
English (en)
French (fr)
Inventor
河野　敏明
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to PCT/JP2017/046905 priority Critical patent/WO2019130469A1/ja
Publication of WO2019130469A1 publication Critical patent/WO2019130469A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling

Definitions

  • the present invention relates to a maintenance design support system that operates in cooperation with a device diagnosis system.
  • Patent Document 1 is an example of a technology that supports the design of an IT system.
  • Patent Document 1 is a general IT system that searches required IT system requirements and generates requirements from comparison of a modeled representation of a known system with a modeled representation of a new system.
  • Maintenance is considered as prior prevention of a failure that may occur or a response method after the occurrence, according to the analysis result of failure modes of the asset to be maintained. For example, reliability-centered maintenance exists as the method. Necessary resource requirements can be formulated by creating business and IT system assumptions in line with the study results.
  • the object of the present invention is to analyze the detailed maintenance operation and IT requirements corresponding to a part of the failure based on the knowledge of the target asset, and to formulate highly accurate maintenance operation and IT system requirements for the entire asset.
  • the purpose is to create a verification plan and present it to users, and further, to generate business / IT system requirements for the entire asset from the verification result based on the presented plan.
  • a maintenance design support system that presents a user with a failure to be evaluated in an asset to the user, and has an HMI with an input / output unit and asset knowledge about the structure, failure, and maintenance content of the asset.
  • An asset knowledge database to be stored, a failure similarity estimation unit for calculating similarity between failure modes of assets using asset knowledge, and a failure mode of a representative to be evaluated from similar failure modes are extracted, and HMI Maintenance design support system characterized by including an evaluation planning unit to present the user as an evaluation plan via
  • FIG. 1 is a diagram showing an example of a schematic configuration of a maintenance design support system according to the present invention.
  • the figure which shows the example of the asset knowledge data D1 memorize
  • Requirements allocation example Requirement definition knowledge 7000 Example of requirement generation result presentation
  • FIG. 1 is a view showing a schematic configuration example of a maintenance design support system according to the present invention.
  • the maintenance design support system 100 presents the representative evaluation target failure D4 to the evaluation performer M who is the user, performs evaluation based on the information presented by the evaluation performer M, and evaluates the evaluation result D5. It is reflected in the maintenance design support system 100.
  • the maintenance design support system 100 configured by a computer system is an asset knowledge data database DB1 for storing asset knowledge data D1 which is knowledge such as failure of a target asset as a database DB for storing various data, and the evaluation result is a requirement
  • a validity determination knowledge database DB2 for storing validity determination knowledge D2 for determining whether it is appropriate for the purpose of the requirements definition database for storing requirements definition knowledge D3 which is knowledge required for requirements definition It has DB3.
  • a fault similarity similarity estimation unit U1 that calculates the similarity between faults of assets using the asset knowledge data D1, and fault similarity Maintenance work from the evaluation plan unit U2 that creates detailed evaluation items (representative evaluation target failure D4) of maintenance work and IT from the degree, the validity determination knowledge D2, the requirements definition knowledge D3 and the evaluation result D5 implemented based on the plan -A request resource estimation unit U3 for estimating the IT request resource D6, and further, as an interface with the user M, the evaluation plan (representative evaluation target fault D4) or the requirement estimation result D6 for the user M And an HMI for inputting the evaluation result D5 from the user M.
  • FIG. 2 is a structural development view of a wind turbine as an application example of diagnosis in the embodiment of the present invention.
  • the windmill 10 which is the target asset is formed with the blade 20, the nacelle 30, and the tower 40 as main components.
  • the blade 20 comprises a plurality of blades 21, 22 and 23
  • the nacelle 30 comprises a main shaft 35, a speed increasing device 31, a generator 32, a pitch control unit 33, a transformer 34 and the like.
  • the main shaft 35, the speed increasing gear 31, the generator 32, the pitch control unit 33, the transformation device 34 and the like are each composed of a plurality of parts illustrated in FIG. 2 although they will not be described one by one. Below, each part and component which form a windmill are called components.
  • the maintenance management is performed up to the unit of the lowermost component.
  • the asset knowledge data database DB1 of FIG. 1 records the structure and failure mode of the wind turbine 10 which is the target asset, the installed condition monitoring system, and the like.
  • FIG. 3 shows an example of asset knowledge data D1 stored in the asset knowledge data database DB1.
  • the component D11 of the wind turbine 10 is illustrated on the vertical axis side. Furthermore, on the horizontal axis side, a function D12, an ID number D13, a failure mode D14, an inspection means D15, a maintenance means D16, a required skill D17 and the like are stored together for each component D11 of the wind turbine.
  • the asset knowledge data D1 is used to create a similarity between failure modes D14 and to classify failure modes D14 into several groups.
  • the fault similarity estimation unit U1 calculates the distance between the contents of the two failure modes, and creates clusters of failure modes by putting together those which are close in distance.
  • the distance to be used is defined with respect to matters that seem to affect the specifications of maintenance work and maintenance IT. The method is shown below.
  • FIG. 4 shows an example of the processing flow in the failure similarity degree estimation unit U1.
  • the start of this flow is determined in processing step S100, and is assumed to be started and received when an execution instruction of evaluation plan creation from user M is received through the HMI.
  • processing step S101 of the failure similarity estimation unit U1 first, the asset knowledge data D1 is read from the asset knowledge data database DB1, and the failure mode (D14 in FIG. 3) included in the failure knowledge data D1 is referenced. Next, by the combination of the processing step S102 and the processing step S105, loop processing is performed on the processing between the processing steps. Loop processing is performed until processing for all combinations of the two selected failure modes D14 is completed.
  • the distance between failure modes is calculated for each of the distance types for the two selected failure modes D14.
  • calculation of distance can be considered from various viewpoints. For example, when calculating the distance from the content of the failure, it is preferable to compare the failure mode descriptions in the failure mode data. If the content of the failure is near, the required maintenance is similar, and it can be inferred that the requirements for business and IT systems are also near.
  • the distance L2 on the asset structure is also conceivable. This is because a structurally similar device may have a similar structure, in which case it is assumed that the maintenance requirements will also be close.
  • the distance calculation using the tree structure shown in Fig. 2 as the structural expansion in the asset knowledge, count how many nodes the leaf assets are separated by the distance L2 I assume.
  • inspection means D15 used is also considered. This is because, if the inspection means is close, it is assumed that the maintenance requirements such as necessary workload, skills, inspection equipment and instruments are close even if they are separate devices. For example, visual inspection of the blades of the wind turbine and visual inspection of the tower are both carried out by workers from the outside through the wind turbine, and it can be estimated that the work flow and the amount of work in implementation are close. Alternatively, in the case of remote diagnosis using a vibrometer, it can be inferred that the collected vibration data is similar whether the object is a bearing or a gear, and that the data capacity and the diagnostic processing load are similar. Also, in the case of state-based maintenance where workers are dispatched based on the results of remote diagnosis, the work flow is considered to be similar.
  • the distance L4 can be defined from the maintenance means D16.
  • FIG. 5 shows an example of calculation of various distances.
  • the business total distance DTA and the IT total distance DTB are illustrated as examples of the total distance DT described below. ing.
  • the distance between the contractual conditions (occurrence penalty, requirement of implementation cycle, safety requirement) for each failure, the price of components, environmental impact (generation of harmful substance), etc. It is possible to calculate from various viewpoints related to maintenance.
  • calculation of the total distance DT between the two failure modes is executed in consideration of various distances (L1, L2, L3, L4) as calculation processing of the total distance DT.
  • various values L 1, L 2, L 3, L 4 are in the same range of units and absolute values, those normalized with the average value of the respective distances L 1 to L 4 are referred to as DN 1 to DN 4 again.
  • the IT total distance DTB can also be determined by weighting basically using the same equation.
  • weighting is different between the task total distance DTA and the IT total distance DTB.
  • W1A 4
  • W4A 5
  • asset knowledge data D1 shown in FIG. 3 used for calculating these distances or distances does not have to be complete for all items, and there exist one or more pieces of asset knowledge data D1 of an arbitrary number of items, The present embodiment can be implemented if the distance calculation for that is performed.
  • FIG. 6 shows an example of the processing flow of the evaluation planning unit U2. The start of this flow is determined in processing step S200, and it is assumed that the process is started and executed when the processing in the failure similarity degree estimation unit U1 in the previous stage is completed.
  • a first iterative process is performed between the process step S201 and the process step S203. This iterative process is executed for each type of total distance (total business distance DTA and total IT distance DTB) obtained by the failure similarity degree estimation unit U1 in the previous stage, and the processing of processing step S202 is performed.
  • the processing of processing step S202 is failure mode grouping processing, in which failure mode D14 is divided into groups based on the degree of similarity between failure modes generated earlier.
  • a cluster is generated in which failure modes D14 close in distance are summarized using the integrated distance of each task and IT (total task distance DTA and IT total distance DTB).
  • the present invention is not limited to a specific method of clustering, here, failure modes are hierarchically clustered using a general clustering algorithm such as the short link method.
  • the failure mode is firstly separated from the total distance (total business distance DTA and total IT distance DTB). It is conceivable to select verification items more accurately by performing clustering using the total distance (business total distance DTA and IT total distance DTB) after dividing D14.
  • division processing by such condition setting is performed under various conditions. For example, when communication means differ depending on the device, and communication by wired cable and wireless communication are separated, or when the data collection cycle in the inspection means is known in advance, the cycle is divided into several stages, and It is possible to evaluate. Alternatively, for each failure mode, if it is necessary to know in advance the number of people required to perform maintenance work and the skills required, it may be possible to divide the system into each condition. Also, these division conditions may be set separately for maintenance work and maintenance IT.
  • the group for maintenance work requirements is divided into skill requirements, and the group for maintenance IT requirements is divided according to sensor types, and then clustering processing is performed.
  • FIG. 7 shows a cluster grouping case for maintenance work.
  • "substation apparatus 34 substation failure" of ID No. ID23 is extracted with respect to "electrical equipment handling" of asset knowledge data D17 of FIG. 3, and with respect to "heavy equipment handling” of asset knowledge data D17 of FIG. "Blade” of ID1, “Blade” of ID No. ID3, “Blade broken” of ID No. ID2, and “Tower 40 deformation” of ID No. ID24 are extracted respectively, and "skill requirement of asset knowledge data D17 of FIG. 3 Regarding “None”, “bearing scratch and wear” of ID No. ID 8 and ID 13, “bearing fixing” of ID No. ID 10, “grease deterioration” of ID No. ID 9 and “alignment deviation” of ID No. 7 are extracted respectively.
  • “skill requirement of asset knowledge data D17 of FIG. 3 Regarding “None”, “bearing scratch and wear” of ID No. ID 8 and ID 13, “bearing fixing” of ID No. ID 10, “greas
  • FIG. 8 shows a cluster grouping case for maintenance IT.
  • “blade crack” of ID No. ID1, “blade crack” of ID No. ID3, “blade broken” of ID No. ID2, ID No. “Tower 40 deformation” of ID 24 is extracted respectively, and “bearing scratch / wear” of ID No. ID 8 and ID 13 and “grease deterioration” of ID No. ID 9 with respect to “remote diagnosis by vibrometer” of inspection means D 15 in FIG.
  • “Alignment misalignment” of ID No. ID 7 is extracted, and “bearing adherence” of ID No. ID 10 is extracted with respect to “remote diagnosis by thermometer” of the inspection means D 15 of FIG. 3 respectively.
  • “function check” “transforming device 34 substation failure” of ID number ID23 is extracted respectively.
  • FIG. 7 and FIG. 8 also show the result of group generation for each divided case.
  • the cases here, they are summarized by the threshold (DTAL and DTBL) of the total distance (total business distance DTA and total IT distance DTB). Cases having similar total distances DT are grasped as the same group using the total distance thresholds DTAL and DTBL in FIGS. 7 and 8.
  • 7 and 8 show that, as a result of adjusting the distance threshold DTAL for business verification and the distance threshold DTBL for IT verification, seven groups for business verification purpose and seven groups for IT verification are generated, respectively. ing. A method of determining the total distance threshold DTAL and DTBL will be described later.
  • FIG. 9 shows a cluster / grouping case for maintenance work
  • FIG. 10 shows a correspondence between an extraction group Gr and a failure mode for a cluster grouping case for maintenance IT.
  • the second iterative process is performed between the process step S204 and the process step S206.
  • This repeated processing is to extract a representative failure mode.
  • the repetitive processing is executed for each type of the total distance (business total distance DTA and IT total distance DTB) in the previous stage, and the processing of processing step S205 is performed.
  • a failure mode representing each group Gr is extracted.
  • the sum of distances to other failure modes in the group is calculated for each failure mode, and ranks are assigned as representative degrees in ascending order of the distance sum. Note that among failure modes having the same distance sum, the order is randomly determined.
  • FIGS. 9 and 10 also show examples of giving representative degrees.
  • the "substation 34 substation failure" of the ID number 23 is a representative example of the group Gr1
  • the "blade crack" of the ID number 1 Represents a case extracted as a representative case of the group Gr2.
  • FIG. 11 shows an example of a method of presenting representative evaluation target failure data D4.
  • FIG. 11 shows an example of presentation in a format to be displayed on a monitor screen.
  • the upper row of the monitor screen 90 is a list format of data of maintenance verification work related items: group, component D11, ID No. D13, failure mode D14, representative degree, inspection means D15, maintenance means D16, request skill D17. Is presented.
  • the maintenance IT-related task verification items are data of group, component D11, ID number D13, failure mode D14, representative degree, inspection means D15, maintenance means D16, and required skill D17. It is presented as a list format.
  • the in-group item selection screen 30000 is selected and displayed.
  • the group item selection screen 30000 collectively displays other cases that belong to the group but are not selected as representative cases. If another case is selected on the in-group item selection screen 30000, the representative case can be changed. For the case recommended by the computer, it is possible to replace the representative case, for example, when the user M determines that the other case is more appropriate.
  • a threshold adjustment screen 31000 is further prepared.
  • the viewpoint of grouping displayed on the monitor screen 90 in FIG. 11 is changed, and the diagram by grouping in a new viewpoint One representative evaluation target failure data D4 can be presented.
  • the processing content of this portion is shown in processing step S208 of FIG.
  • the user M approves the presented content on the approval screen 33000.
  • the user M it is possible for the user M to be presented in order from the failure mode with the highest degree of representativeness, and to select an appropriate one for verification execution.
  • a plurality of groups may be selected if the user determines that evaluation can be performed.
  • an effect of improving the accuracy of the evaluation is expected.
  • By selecting a failure mode that proves to be easy to verify it is also possible to facilitate the operation.
  • verification items for business and IT are respectively arranged in the upper and lower rows, and representative failure modes for each group are displayed. Further, by clicking the pull-down button in the group column, a list of all failure modes in the group is presented, and it is possible to select a failure mode to be evaluated.
  • the distance threshold DTAL or DTBL is increased in the group division adjustment processing step S208 of FIG.
  • the number of groups generated is reduced by re-executing the conversion processing step S202.
  • the number of generated groups can be increased by reducing the distance threshold DTAL or DTBL.
  • adjustment is made possible by changing the distance threshold DTAL or DTBL on the threshold adjustment screen 31000 and updating the list contents with the distance threshold by pressing the update button.
  • a method may be considered in which a hierarchy is generated for each part based on the clustering result, instead of having one distance threshold for each task and IT.
  • FIG. 12 shows a user presentation screen example 93 of the result of clustering for work in that case.
  • the relationships shown in FIG. 7 and FIG. 8 are displayed and displayed, and the determination button 1000 is used to determine the user M.
  • group generation is performed by adding, deleting, and moving an icon 35000 for selecting a group generation hierarchy on the graph, and six groups are generated in the example.
  • the failure mode to be evaluated for work and the failure mode to be evaluated for IT as much as possible so that the entire evaluation can be completed with verification for a small number of failure modes.
  • the group of failure modes corresponding to each business / IT is extracted in order from the smallest representative of business / IT given to each failure mode in order of increasing representative degree, and duplication is performed.
  • extraction is impossible without extraction, it is conceivable to extract the highest representative from each group to which representative is not extracted, and present it to the user.
  • a display example is shown in FIG.
  • Representativeness, job verification D18, and IT verification D19 data can also be displayed together.
  • the confirmation button 34000 it is good for the confirmation button 34000 to prepare what can confirm confirmation and denial.
  • the user M who has received the evaluation plan D4 (representative evaluation target failure) is required for the maintenance work when actually performing maintenance of periodic inspection and diagnostic technology utilization with respect to the target failure mode.
  • Requirements such as human resources (person ⁇ hour), business skills, communication capacity necessary for using diagnostic IT technology, storage capacity, IT resources such as CPU time, etc., technology application test or computer simulation, desktop study etc. Measure from
  • the measurement result is the evaluation result data D5 of FIG.
  • An example of the measurement result data D5 is shown in FIG.
  • information of the verification result by the user M is added for each case (specified in the component D11, ID field number D13, failure mode D14) recommended by the computer and approved by the user M. ing.
  • the information on the verification result is roughly classified into a verification result (business requirement verification result) D5A on the business requirement and a verification result (IT requirement verification result) D5B on the IT requirement.
  • the task requirement verification result D5A is further separately grasped as a verification result (inspection task verification result) D5A1 for inspection task and a verification result (maintenance task verification result) D5A2 for maintenance task.
  • the IT requirement verification result D5B, the inspection task verification result D5A1, and the maintenance task verification result D5A2 are further described by being classified into quantitative requirements (D5A11, D5A21, D5B1) and qualitative requirements (D5A12, D5A22, D5B2).
  • the evaluation result data D5 is input to the maintenance design support system 100 through the HMI.
  • FIG. 15 shows a process flow in the request resource estimation unit U3.
  • the quantitative and qualitative requirements D5A11 and D5A12 of the inspection job the quantitative and qualitative requirements of the maintenance job D5A21, D5A22, the quantitative and qualitative requirement of IT in the large frame repetitive processing.
  • Repeated processing is performed on each of D5B1 and D5B2.
  • large-scale repetitive processing such as IT quantitative requirements
  • loop processing is performed for each type of failure mode in the small frame repetition processing.
  • the validity determination knowledge data D2 includes, for each consecutive number D21, a related requirement type D22 and a condition D23 which determines that the evaluation result is invalid, and an example thereof is shown in FIG. As shown in FIG. 16, data D24 for explanation of reasons may be included to present the reason judged to be invalid to the user.
  • the validity determination knowledge data D2 As an example of the validity determination knowledge data D2, as the case where the serial number D21 is “1”, the related requirement type D22 is "business requirement / inspection", and the invalid determination condition D23 is "mixture of different skill requirements” In this case, “worker dispatching another skill holding is necessary” is stored as knowledge in the reason D24 which is judged to be invalid. Also, as a case where the serial number D21 is “2”, when the related requirement type D22 is “IT requirement / communication” and the invalid judgment condition D23 is “mixture of communication speed requirement 50 kbps or more and less than 50 kbps” In the reason D24 which is judged appropriate, “Wifi is required in the case of 50 kbps or more. Bluetooth (registered trademark) is possible in the case of less than 50 kbps” is stored as knowledge.
  • ID No. of failure mode is ID8 from Gr4, “Bearings and wear of bearing of bearing”, ID No.
  • the inspection and evaluation on the case of “ID bearing grease degradation” is performed by the user M, and the evaluation result is presented to the maintenance design support system 100 which is a computer.
  • ID 8 is 5 kbps
  • ID 9 is 100 Kbps.
  • the group Gr4 of IT requirements is divided for the user M in the group redivision processing step S305 of FIG. Ask them to regroup the modes into separate groups.
  • the process may return to the process of the evaluation planning unit U2 of FIG. 1, adjust the distance threshold of the group generation condition, and reselect the verification item.
  • the user M redefines the failure mode whose requirement is closer to the content of the ID number ID8, Gr4-A, and the failure mode whose requirement is closer to the content of the ID number ID9 is Gr4-B.
  • the quantitative requirement is to average the values
  • the qualitative requirement is to list all the requirements together without duplication.
  • the work volume is converted into an average work volume demand on an annual basis based on the work implementation cycle and frequency, and is presented as the required number of people.
  • FIG. 17 shows an example of the result of requirement assignment.
  • the items on the horizontal axis of FIG. 17 basically conform to the display format of the evaluation result example of FIG. 14 but newly add group columns D5A0 and D5B0.
  • D5A0 defines a group in the task requirement verification result D5A
  • D5B0 defines a group in the IT verification result D5B.
  • a group is a group as illustrated in FIGS. 7 to 10, and is a group defined by the reconstruction of the group in the group re-division processing step S305 in FIG.
  • ID number 1 of the evaluation result example in FIG. 14 is group Gr2
  • ID number 2 is group Gr3
  • ID number 7 is group Gr7
  • ID numbers 8, 10, 13 are groups Gr5, ID number 9 is group Gr6, ID number 23 is group Gr1, and ID number 24 is group Gr4.
  • the ID numbers (1, 2, 7-9, 13, 23, 24) to which background color is added in the group columns D5A0, D5B0 are the evaluation results in FIG. ID numbers (3, 5, 15, 19) that are the cases described in the display format (existing cases) but with no background color in the group columns D5A0 and D5B0 are newly added by requirement assignment. Project (new project).
  • the new cases of ID numbers 3 and 5 classified into group Gr2 have the reason that the validity verification of ID number 1 is insufficient due to the requirement assignment of the existing cases of ID number 1 classified into the same group Gr2 , It is the case that was requested to be newly added.
  • the new case of the ID number 15 classified into the group Gr5 is the validity verification of the ID numbers 8, 10, 13 by the requirement assignment of the existing cases of the ID numbers 8, 10, 13 classified into the same group Gr5 Is an item that is required to be newly added because it is insufficient.
  • New projects of ID No. 19 classified into group Gr6 are newly added because the requirement verification of the existing projects of ID No. 9 classified into the same group Gr6 is insufficient for validation of ID No. 9 This item is required to be added.
  • FIG. 18 shows an example of the requirement definition knowledge D3.
  • the requirement definition knowledge D3 of FIG. 18 includes a serial number D31, a condition D32, and an additional requirement D33.
  • the condition D32 in the requirement definition knowledge D3 is compared with the result of requirement assignment, and if there is a corresponding item, it is extracted as an additional requirement.
  • the business and IT requirements allocated to the all failure mode in the above processing are integrated to generate the business and IT requirements (requirements and resource estimate D6) for the maintenance of the target asset.
  • quantitative requirements such as workload, storage, and CPU computational requirements are summed up and presented to the user.
  • the work volume is converted into an average work volume demand on an annual basis based on the work implementation cycle and frequency, and is presented as the required number of people.
  • Qualitative requirements aggregate items without duplication and present them to users.
  • FIG. 19 shows a presentation example of the requirement / resource estimate D6.
  • the horizontal axis items in this case are a business requirement D6A, an IT requirement D6B, a total business requirement D6C, and an additional requirement D6D, and the business requirement D6A is further subdivided into an inspection business requirement D6A1 and a maintenance business requirement D6A2.
  • inspection business requirements D6A1, maintenance business requirements D6A2, IT requirements D6B, total business requirements D6C are described separately in quantitative requirements (D6A11, D6A21, D6B1, D6C1) and qualitative requirements (D6A12, D6A2, D6B2, D6C2) ing.
  • the requirement generation result (requirement / resource estimate D6) is presented to the user M through the HMI.
  • DB1 Asset knowledge database
  • DB2 Validity determination knowledge database
  • DB3 Requirements definition knowledge database
  • D1 Asset knowledge
  • D2 Validity determination knowledge
  • D3 Requirements definition knowledge
  • D4 Representative evaluation Target fault
  • D5 Evaluation result
  • D6 Requirement / resource estimation
  • M Evaluator
  • U1 Failure similarity estimation unit
  • U2 Evaluation planning unit
  • U3 Requested resource estimation unit

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Tourism & Hospitality (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

対象アセットの知識に基づき、一部の故障に対応する詳細な保全業務・ＩＴ要件の分析のみで、アセット全体に対する精度の高い保全業務・ＩＴシステムの要件策定が可能な検証計画を立案してユーザーに提示し、またさらには、提示した計画に基づいた検証結果から、アセット全体の業務・ＩＴシステム要件を生成する。アセットにおける評価対象故障をユーザーに提示する保全設計支援システムであって、入出力部を備えたＨＭＩと、アセットの構造、故障、保全内容についてのアセット知識を記憶するアセット知識データベースと、アセット知識を用いてアセットの故障モード間の類似度を算出する故障類似度推定ユニットと、類似の故障モードの中から評価対象とする代表の故障モードを抽出し、ＨＭＩを介してユーザーに評価計画として提示する評価計画ユニットを備えることを特徴とする保全設計支援システム。

Description

保全設計支援システム
　本発明は、機器の診断システムと連携して動作する保全設計支援システムに関する。
　インフラ、鉄道、産業機器、医療機器などの多くの分野では、アセットの導入後は保全を継続的に実施することで、所定の性能を維持する必要がある。保全においては対象アセットの状態を収集し、異常の有無や問題点を分析する診断を適用した上で、適切な保全作業を適用する。
　近年の情報技術の発達により、アセットの状態をセンサで収集し、アセットの現在の状態を把握するか、あるいは将来状態を予測する診断技術などのＩＴ技術を用いることで、保全を適切な内容・タイミングで実施することで、保全コストを低減しつつ、信頼性を向上することが可能となっている。
　しかしそのためには、診断と連携した従来と異なる保全プロセスを導入する必要があり、それに伴い人員数や必要な技能、器具などの保全の業務リソースが大きく変化することになる。また、新しいＩＴ技術の導入には、システムの更新が必要であり、センサや分析方式によっては、大容量ストレージや、大きな計算能力などのＩＴリソースが必要となる。
　そのため、保全の業務・ＩＴ設計を適切に実施することが必要であり、特に適切な要求リソースを設定することは、保全業務の実施可能性と持続性のために、重要となっている。過小な業務リソースでは、新しいＩＴ技術を用いた新しい保全プロセスが実行不可となり、過大な業務リソースでは、コストの増大により、保全業務の継続性が保障できず、結果的に保全品質が低下する。また、特に保全ＩＴシステムが過小リソースの場合は、センサデータの受領・記録が不可能となることや、分析が不可能あるいは所定時間内に終了しないといった問題が発生する。一方でＩＴリソースが過大の場合は、やはりコストの増大を招くこととなる。
　従って、保全業務・ＩＴの企画・設計において、導入する診断技術に適したリソース要求見積もりを支援することで、実施可能かつ効率的な保全を実現することが必要となる。
　必要なリソースの見積もり方法のうち、ＩＴシステムの設計をサポートする技術の例としては、特許文献１がある。
　特許文献１は、一般のＩＴシステムにおいて、既知のシステムのモデル化表現と、新システムのモデル化表現の比較から、必要なＩＴシステム要件を検索して、要件を生成するものである。
特開２０１７－４５３６１号公報
　保全業務・ＩＴシステムの要件策定においては、実施上の困難が存在する。保全は、保全の対象となるアセットの故障モードの分析結果に応じて、発生しうる故障の事前防止、あるいは発生後の対応方法として、検討される。例えばその方法として、信頼性中心保全などが存在している。検討結果に沿った業務とＩＴシステムの想定を作成することで、必要なリソース要件を策定することができる。
　特に、状態監視や診断などの新しい保全技術を導入する場合は、新技術を適用する故障モードごとに、詳細な実証実験や机上検討を行うことで、新技術に対応した業務フローに応じた業務リソースや、ＩＴリソースを準備することが考えられる。しかし、対象アセットの故障モードは一般に多数存在しており、すべての故障モードに対して業務・ＩＴの詳細検討を行い、要件を作成することは、実務上大きな負担であり、その実施労力、時間、費用のために、非常に困難である。
　そのため、保全業務・ＩＴ要件設計において、十分な要件検証が実施されず、不十分な根拠に基づく保全業務・ＩＴ要件のために、過剰なリソースを要求してしまい、高コストな保全組織・ＩＴシステムを導入する、あるいは導入計画自体が頓挫することがありうる。あるいは、過小なリソース要求のために、実際の業務において、作業人員不足や必要スキルを持った人材の不足、あるいはＩＴシステムの能力不足により、例えば装置の診断に非常に大きな時間を要する、一部装置しか監視・診断ができない、診断の性能が低下するといった事態を招く危険がある。
　そこで本発明の目的は、対象アセットの知識に基づき、一部の故障に対応する詳細な保全業務・ＩＴ要件の分析のみで、アセット全体に対する精度の高い保全業務・ＩＴシステムの要件策定が可能な検証計画を立案してユーザーに提示し、またさらには、提示した計画に基づいた検証結果から、アセット全体の業務・ＩＴシステム要件を生成することである。
　以上のことから本発明においては、「アセットにおける評価対象故障をユーザーに提示する保全設計支援システムであって、入出力部を備えたＨＭＩと、アセットの構造、故障、保全内容についてのアセット知識を記憶するアセット知識データベースと、アセット知識を用いてアセットの故障モード間の類似度を算出する故障類似度推定ユニットと、類似の故障モードの中から評価対象とする代表の故障モードを抽出し、ＨＭＩを介してユーザーに評価計画として提示する評価計画ユニットを備えることを特徴とする保全設計支援システム」としたものである。
　本発明を用いることで、適切な保全業務・ＩＴ業務検証計画を立案し、少数の検証結果から、アセット全体の保全業務・ＩＴ要件を、効率的かつ精度よく策定することが可能となり、保全設計業務の効率化と、適切な保全業務・ＩＴ構築が可能となる。
本発明に係る保全設計支援システムの概略構成例を示す図。 本発明の実施例において診断の適用事例とした風車の構造展開を示す図。 アセット知識データデータベースＤＢ１に記憶されているアセット知識データＤ１の例を示す図。 故障類似度推定ユニットＵ１における処理フローの例を示す図。 各種の故障間距離算出例を示す図。 評価計画ユニットＵ２における処理フローの例を示す図。 保全業務向けクラスタ・グループ化の例を示す図。 保全ＩＴ向けクラスタ・グループ化の例を示す図。 保全業務向けクラスタ・グループ化事例についての抽出グループＧｒと故障モードの対応関係を示す図。 保全ＩＴ向けクラスタ・グループ化事例についての抽出グループＧｒと故障モードの対応関係を示す図。 代表評価対象故障データＤ４の提示方法の例を示す図。 業務向けクラスタリング結果のユーザー提示画面例９３を示す図。 評価対象故障モード一覧表示例を示す図。 測定結果データＤ５の例を示す図。 要求リソース推定ユニットＵ３における処理フローの例を示す図。 妥当性判定知識データＤ２のデータ構造例を示す図。 要件割り当て例 要件定義知識７０００ 要件生成結果提示例
　以下、本発明の実施例について図面を用いて説明する。
　図１は、本発明に係る保全設計支援システムの概略構成例を示す図である。
　図１において、保全設計支援システム１００は、ユーザーである評価実施者Ｍに代表評価対象故障Ｄ４を提示し、評価実施者Ｍが提示された情報に基づいて評価を実施し、その評価結果Ｄ５を保全設計支援システム１００に反映させる。
　これにより、ユーザーである評価実施者Ｍの負担を軽減するとともに、適切な保全業務・ＩＴ業務検証計画を立案し、少数の検証結果から、アセット全体の保全業務・ＩＴ要件を、効率的かつ精度よく策定することが可能となり、保全設計業務の効率化と、適切な保全業務・ＩＴ構築が可能となる。
　計算機システムにより構成される保全設計支援システム１００は、各種のデータを記憶するデータベースＤＢとして、対象アセットの故障などの知識であるアセット知識データＤ１を記憶するアセット知識データデータベースＤＢ１、評価結果が要件策定の目的のために妥当なものであるかを判定するための妥当性判定知識Ｄ２を記憶する妥当性判定知識データベースＤＢ２、要件定義に必要な知識である要件定義知識Ｄ３を記憶する要件定義知識データベースＤＢ３を備えている。
　また計算機システムにより構成される保全設計支援システム１００は、その処理内容を機能別に記述すると、アセット知識データＤ１を用いてアセットの故障間の類似度を算出する故障類似度推定ユニットＵ１と、故障類似度から保全業務・ＩＴの詳細評価項目（代表評価対象故障Ｄ４）を作成する評価計画ユニットＵ２と、妥当性判定知識Ｄ２と要件定義知識Ｄ３と計画に基づいて実施された評価結果Ｄ５から保全業務・ＩＴの要求リソースＤ６を推定する要求リソース推定ユニットＵ３とを備えたものであり、さらにユーザーＭとの間でのインターフェイスとして、ユーザーＭに評価計画（代表評価対象故障Ｄ４）や要件見積もり結果Ｄ６を提示し、ユーザーＭから評価結果Ｄ５を入力するＨＭＩを備えている。
　以下、保全設計支援システム１００の各部の構成と機能を、処理の流れに従って詳細に説明する。なお、本発明は、特定のアセット、センサ技術、分析技術に限定されるものではないが、具体的な適用事例として風車の診断を例として、以降の説明を行う。
　図２は、本発明の実施例において診断の適用事例とした風車の構造展開図である。この例によれば、対象アセットである風車１０は、ブレード２０、ナセル３０、タワー４０を主たる構成要素として形成されている。またブレード２０は複数のブレード２１、２２、２３、ナセル３０はメインシャフト３５、増速機３１、発電機３２、ピッチ制御部３３、変電装置３４などにより構成されている。またさらにメインシャフト３５、増速機３１、発電機３２、ピッチ制御部３３、変電装置３４などは、逐一説明はしないがそれぞれが図２に図示するところの複数の部品で構成されている。以下においては、風車を形成する各部や部品をコンポーネントということにする。図２に示した対象アセットの構造展開では、最下層のコンポーネントの単位まで、保全の管理を実施するものとする。
　係る構造の風車では、特に主軸３５の軸受けベアリング３５ｂ、発電機３２、ブレーキ、ピッチ制御部３３などの各所について、事前に予測する予兆診断の適用が考えられる。また、ウィンドファームや遠隔地風車の監視を考えた場合、非常に多くの風車を同時に監視し、保全管理する状況が考えられる。
　図１のアセット知識データデータベースＤＢ１は、対象アセットである風車１０の構造や故障モード、導入済みの状態監視システムなどを記録している。図３に、アセット知識データデータベースＤＢ１に記憶されているアセット知識データＤ１の例を示す。
　図３に示すアセット知識データＤ１の例では、縦軸側に風車１０のコンポーネントＤ１１を例示している。さらに横軸側には、風車のコンポーネントＤ１１ごとに、機能Ｄ１２、ＩＤ番号Ｄ１３、故障モードＤ１４、検査手段Ｄ１５、保全手段Ｄ１６、要求スキルＤ１７などを併せて記憶している。
　この例におけるアセット知識データＤ１では、対象アセットの構造展開において最下層のコンポーネントの単位まで、保全の管理を実施するものとし、さらに図３では展開されたコンポーネントＤ１１の機能Ｄ１２及び、故障モードＤ１４などをリスト化したものである。また、各故障モードＤ１４に対して、利用可能な検査手段Ｄ１５や、その実施スケジュールや要求スキルＤ１７もリスト化されているものとする。これらの検査手段や実施スケジュールは、対象の故障モードの特性（劣化進展のパターン、検出に適したセンサなど）の検討によって、決定されるものである。
　図１の故障類似度推定ユニットＵ１では、アセット知識データＤ１を用いて、故障モードＤ１４間の類似度を作成し、故障モードＤ１４をいくつかのグループに分類する。故障類似度推定ユニットＵ１では、２つの故障モード間の内容の距離を算出して、距離が近いもの同士を纏めることで、故障モードのクラスタを作成する。使用する距離は、保全業務や保全ＩＴの仕様に影響すると思われる事項に対して定義する。以下、その方法を示す。
　図４に、故障類似度推定ユニットＵ１における処理フローの例を示す。このフローの開始は、処理ステップＳ１００において判断され、ユーザーＭから評価計画作成の実行指示を、ＨＭＩを通じて受領したときに開始実行されるものとする。
　故障類似度推定ユニットＵ１の処理ステップＳ１０１では、はじめにアセット知識データデータベースＤＢ１からアセット知識データＤ１を読み込み、故障知識データＤ１中に含まれる故障モード（図３のＤ１４）を参照する。次に、処理ステップＳ１０２と処理ステップＳ１０５の組み合わせにより、この処理ステップ間の処理に対してループ処理を行う。ループ処理は、選ばれた２つの故障モードＤ１４についての全ての組み合わせに対する処理が完了するまで行われる。
　処理ステップＳ１０３では、選ばれた２つの故障モードＤ１４に対して、故障モード間の距離を距離種別ごとに算出する。ここで距離の算出では、様々な観点からの算出が考えられる。例えば、故障の内容から距離を算出する場合、故障モードデータ中の、故障モード記述間の比較を行うのがよい。故障の内容が近ければ、要求される保全も類似しており、業務・ＩＴシステムへの要件も近いと推測できる。
　比較の方法としては、テキストのマッチングから、類似度の高い項目間の距離を小とすることが考えられる。本実施例の場合、図３に示すアセット知識データＤ１の故障モード欄Ｄ１４間で、単語のマッチングを取り、全単語種類Ｎ個に対する不一致単語種類Ｍ個の割合を距離Ｌ１＝Ｍ／Ｎとすることが考えられる。例えば、ＩＤ番号欄Ｄ１３について、ＩＤ１とＩＤ３の故障モードＤ１４の間では、“ブレード”、“ヒビ”の２単語が一致しており、全単語種類３なので、Ｌ１＝２／３とすることができる。
　また、アセット構造上の距離Ｌ２も考えられる。これは、構造上近い装置は、近い構造を持つ可能性があり、その場合は保全要件も近くなると推測されるためである。距離計算では図２で示された、アセット知識中の構造展開が木構造であることを用いて、葉となっているアセット間が、いくつのノードで隔てられているかを数え、それを距離Ｌ２とする。例えば、ブレード１（２１）とブレード２（２２）の間の距離は、間にブレード２０のノードひとつがあるのでＬ２＝１、ブレード１（２１）とシャフト３５の間は、ブレード２０・ナセル３０・メインシャフト３５の３つのノードがあるので、Ｌ２＝３とすることができる。
　また、使用される検査手段Ｄ１５を用いた距離も考えられる。これは、検査手段が近い場合は、別々の装置であっても、必要な業務量やスキルや検査用設備・器具などの保全上の要件は近いと推測されるためである。例えば、風車のブレードの目視点検とタワーの目視点検は、どちらも風車に赴いて外部から作業員が実施するものであり、実施上の業務フローや作業量は近いと推測できる。あるいは、振動計を用いた遠隔診断である場合、対象がベアリングでもギアでも、収集する振動データは類似しており、データ容量や診断処理負荷には類似性があると推測できる。また、遠隔診断結果に基づいて作業員が派遣されるような状態基準保全の場合、業務フローも類似すると考えられる。
　検査手段Ｄ１５による距離の算出においては、実施手段の一致度を故障内容の一致度と同様に単語の一致度で調べて距離Ｌ３とすることが考えられる。同様に保全手段Ｄ１６からも距離Ｌ４を定義できる。
　図５に、各種の距離の算出例を示している。ここでは上記説明の故障内容距離Ｌ１、構造距離Ｌ２、検査手段距離Ｌ３、保全手段距離Ｌ４の他に、以下に説明する総合距離ＤＴの事例として、業務総合距離ＤＴＡ、ＩＴ総合距離ＤＴＢを例示している。なお、ほかの距離の算出方法としては、例えば、故障ごとの契約上の条件（発生時ペナルティ、実施周期の要求、安全要求）間の距離、コンポーネントの価格、環境影響（有害物質の発生）など、保全に関係する様々な観点から算出することが可能である。
　図４の処理ステップＳ１０４では、総合距離ＤＴの算出処理として、各種の距離（Ｌ１、Ｌ２、Ｌ３、Ｌ４）を考慮した、２故障モード間の総合距離ＤＴの算出を実行する。ここではまず、各種距離（Ｌ１、Ｌ２、Ｌ３、Ｌ４）は単位や絶対値の値域を揃えるため、それぞれの距離Ｌ１～Ｌ４の平均値で規格化したものを、改めてＤＮ１～ＤＮ４とする。
　次に全ての距離（Ｌ１～Ｌ４）を総合する手法として、その重要度に基づいて重み付け和をとった総合距離ＤＴを生成することが考えられる。このときに、一つの総合距離ＤＴではなく、複数の距離に分けて定義することで、保全の業務・ＩＴ要件を、より詳細に評価する評価計画を立案することが可能となる。例えば、保全の人的リソースである業務要件に関係する業務総合距離ＤＴＡと、ＩＴシステムの要件に関係するＩＴ総合距離ＤＴＢに分離して定義することができる。
　業務総合距離ＤＴＡの場合、ＤＴＡ＝Ｗ１Ａ×ＤＮ１＋Ｗ２Ａ×ＤＮ２＋Ｗ３Ａ×ＤＮ３＋Ｗ４Ａ×ＤＮ４、ＤＴＢ＝Ｗ１Ｂ×ＤＮ１＋Ｗ２Ｂ×ＤＮ２＋Ｗ３Ｂ×ＤＮ３＋Ｗ４Ｂ×ＤＮ４として求めることができ、それぞれの重みを、ＤＴＡに関しては人が実施する。ＩＴ総合距離ＤＴＢも基本的には同じ式を用いて、重みづけにより求めることができる。
　但し、業務総合距離ＤＴＡとＩＴ総合距離ＤＴＢでは、重みづけする考え方が相違している。例えば業務総合距離ＤＴＡの場合には、対象コンポーネンと修理・交換業務内容に関係が深い、アセットの構造である検査手段Ｄ１５、保全手段Ｄ１６に関する重みＷを大きくとるなどして、例えばＷ１Ａ＝４、Ｗ２Ａ＝１、Ｗ３Ａ＝４、Ｗ４Ａ＝５とする。
　一方で、ＩＴシステムの要件に関係する総合距離ＤＴＢの場合には、診断を主に行うＩＴシステムの要件に、アセットの構造や保全手段Ｄ１６は無関係なので、Ｗ１Ａ＝０、Ｗ２Ａ＝１、Ｗ３Ａ＝４、Ｗ４Ａ＝０などととることが考えられる。
　このように定義された故障モード間の距離は、保全業務・ＩＴに関連する事項の類似性で定義したものであるため、距離が小さい故障モード間では、保全業務・ＩＴの要件が近くなっていると期待できる。
　なお、これらの距離あるいは距離算出に使われる図３に示したアセット知識データＤ１は、すべての項目が完備している必要は無く、ひとつ以上、任意の項目数のアセット知識データＤ１が存在し、それに対する距離算出がなされれば、本実施例は実行可能である。
　図１において、次に評価計画ユニットＵ２では、故障類似度推定ユニットＵ１で生成された故障モードのグループを用いて、詳細な保全業務・ＩＴ評価の実施計画を作成する。
　図６に、評価計画ユニットＵ２の処理フローの例を示す。このフローの開始は、処理ステップＳ２００において判断され、前段の故障類似度推定ユニットＵ１での処理が終了しタことをもって、開始実行されるものとする。
　図６の最初の処理では、処理ステップＳ２０１と処理ステップＳ２０３の間で、第１の繰り返し処理を実施する。この繰り返し処理は前段の故障類似度推定ユニットＵ１で求めた総合距離（業務総合距離ＤＴＡとＩＴ総合距離ＤＴＢ）の種類ごとに実行され、処理ステップＳ２０２の処理が行われる。
　処理ステップＳ２０２の処理は、故障モードグループ化処理であり、ここでは先に生成された故障モード間の類似度に基づいて、故障モードＤ１４をグループに分割する。業務・ＩＴそれぞれの総合距離（業務総合距離ＤＴＡとＩＴ総合距離ＤＴＢ）を用いて、距離が近い故障モードＤ１４をまとめた、クラスタを生成する。本発明においてはクラスタリングの具体的な方法には限定されないが、ここでは短リンク法などの一般的なクラスタリングアルゴリズムを用いて、階層的に故障モードをクラスタ化することとする。
　また、処理ステップＳ２０２の故障モードグループ化処理におけるクラスタリング処理において、特に保全業務・ＩＴ決定上重要な要件がある場合、総合距離（業務総合距離ＤＴＡとＩＴ総合距離ＤＴＢ）とは別に先に故障モードＤ１４を分割した上で、それぞれに対して総合距離（業務総合距離ＤＴＡとＩＴ総合距離ＤＴＢ）を用いたクラスタリングを行うことで、より正確に検証項目を選定することが考えられる。
　例えば、ＩＴ要件を策定することを想定すると、振動計による測定と温度計による測定など、センサの違いは、取得データの内容やデータ量に対して決定的な違いを持つと思われる。そこで、センサが違う場合は確実に異なるグループに分割され、それぞれが検証されるように、あらかじめセンサあるいは検出手段ごとに故障モードを大きく分割し、各分割内で、総合距離を用いたクラスタリング処理を行うのがよい。
　このような条件設定による分割処理は、様々な条件に対して実施することが考えられる。例えば、装置により通信手段が異なり、有線ケーブルによる通信と無線通信が分かれる場合や、検査手段におけるデータ収集周期が事前にわかっている場合は、周期をいくつかの段階に分けて、それぞれに対して評価することが考えられる。あるいは、各故障モードに対して、保全作業を実施する際に必要な人数や要求されるスキルがあらかじめわかっている場合は、それぞれの条件ごとに分割することも考えられる。また、これらの分割条件は、保全作業向け、保全ＩＴ向けで別々に設定されても良い。
　本実施例では、保全作業要件向けのグループはスキル要求、保全ＩＴ要件向けのグループはセンサ種類によって分割したうえで、クラスタリング処理が実施されたと仮定する。
　クラスタリング処理の適用により、故障モードＤ１４が階層クラスタリングされた結果を図７と図８に示す。
　図７は、保全業務向けクラスタ・グループ化事例を示している。この事例では、図３のアセット知識データＤ１７の「電機設備扱い」に関して、ＩＤ番号ＩＤ２３の「変電装置３４変電不良」が抽出され、図３のアセット知識データＤ１７の「重機扱い」に関して、ＩＤ番号ＩＤ１の「ブレードヒビ」、ＩＤ番号ＩＤ３の「ブレードヒビ」、ＩＤ番号ＩＤ２の「ブレード折れ」、ＩＤ番号ＩＤ２４の「タワー４０変形」が夫々抽出され、図３のアセット知識データＤ１７の「スキル要件なし」に関して、ＩＤ番号ＩＤ８、ＩＤ１３の「ベアリング傷・摩耗」、ＩＤ番号ＩＤ１０の「ベアリング固着」、ＩＤ番号ＩＤ９の「グリス劣化」、ＩＤ番号ＩＤ７の「アライメントずれ」が夫々抽出されたものとする。
　また図８は、保全ＩＴ向けクラスタ・グループ化事例を示している。この事例では、図３の検査手段Ｄ１５の「目視による異常発生時検査」に関して、ＩＤ番号ＩＤ１の「ブレードヒビ」、ＩＤ番号ＩＤ３の「ブレードヒビ」、ＩＤ番号ＩＤ２の「ブレード折れ」、ＩＤ番号ＩＤ２４の「タワー４０変形」が夫々抽出され、図３の検査手段Ｄ１５の「振動計による遠隔診断」に関して、ＩＤ番号ＩＤ８、ＩＤ１３の「ベアリング傷・摩耗」、ＩＤ番号ＩＤ９の「グリス劣化」、ＩＤ番号ＩＤ７の「アライメントずれ」が夫々抽出され、図３の検査手段Ｄ１５の「温度計による遠隔診断」に関して、ＩＤ番号ＩＤ１０の「ベアリング固着」が夫々抽出され、図３の検査手段Ｄ１５の「機能確認」に関して、ＩＤ番号ＩＤ２３の「変電装置３４変電不良」が夫々抽出されたものとする。
　図７及び図８には、各分割事例についてグループ生成した結果も併せて示している。各事例をグループ分けするに際し、ここでは総合距離（業務総合距離ＤＴＡとＩＴ総合距離ＤＴＢ）の閾値（ＤＴＡＬとＤＴＢＬ）で纏めている。図７、図８の総合距離閾値ＤＴＡＬ、ＤＴＢＬを用いて、同じような総合距離ＤＴを有する事例同士を同じグループとして把握していく。
　図７の保全業務向けクラスタ・グループ化事例では、ある大きさの業務総合距離閾値ＤＴＡＬのときに、ＩＤ番号ＩＤ２３の「変電装置３４変電不良」がグループＧｒ１に区分され、図３のアセット知識データＤ１７の「重機扱いスキル」に関して、ＩＤ番号ＩＤ１の「ブレードヒビ」とＩＤ番号ＩＤ３の「ブレードヒビ」がグループＧｒ２に区分され、ＩＤ番号ＩＤ２の「ブレード折れ」がグループＧｒ３に区分され、ＩＤ番号ＩＤ２４の「タワー４０変形」がグループＧｒ４に区分され、図３のアセット知識データＤ１７の「スキル要件なし」に関して、ＩＤ番号ＩＤ８とＩＤ１３の「ベアリング傷・摩耗」、ＩＤ番号ＩＤ１０の「ベアリング固着」がグループＧｒ５に区分され、ＩＤ番号ＩＤ９の「グリス劣化」がグループＧｒ６に区分され、ＩＤ番号ＩＤ７の「アライメントずれ」がグループＧｒ７に区分されたものとする。なお、業務総合距離閾値ＤＴＡＬをさらに大きな値に設定した場合に、さらに上位でのグループわけが実行されていく。
　図８の保全ＩＴ向けクラスタ・グループ化事例でも同様にしてグループ生成した結果を示しているが、各グループについての詳細説明は割愛する。図７、図８の例では、業務検証に関する距離閾値ＤＴＡＬ、ＩＴ検証に関する距離閾値ＤＴＢＬを調整した結果として、それぞれ業務検証むけ７個、ＩＴ検証向け７個のグループＧｒが生成されタことを示している。なお総合距離閾値ＤＴＡＬ、ＤＴＢＬの決定方法について、後述する。
　抽出されたグループＧｒと故障モードの対応関係を図９及び図１０に示している。図９は、保全業務向けクラスタ・グループ化事例、図１０は保全ＩＴ向けクラスタ・グループ化事例についての抽出グループＧｒと故障モードの対応関係である。
　図６の次段の処理では、処理ステップＳ２０４と処理ステップＳ２０６の間で、第２の繰り返し処理を実施する。この繰り返し処理は、代表故障モードを抽出するものである。この繰り返し処理は前段の総合距離（業務総合距離ＤＴＡとＩＴ総合距離ＤＴＢ）の種類ごとに実行され、処理ステップＳ２０５の処理が行われる。
　代表故障モード抽出処理ステップＳ２０５では、各グループＧｒを代表する故障モードを抽出する。この方法としては、本実施例では、故障モードごとに、グループ内の他の故障モードへの距離の和を計算し、距離の和が小さい順に順位を代表度として付与する。なお、距離和が同じ故障モードの間では、ランダムに順位を決めるものとする。
　図９及び図１０には、代表度の付与例を併せて示している。例えば、図９の保全業務向けクラスタ・グループ化事例のグループＧｒ１では、ＩＤ番号２３の「変電装置３４変電不良」がグループＧｒ１の代表事例であり、グループＧｒ２では、ＩＤ番号１の「ブレードひび」がグループＧｒ２の代表事例として抽出されたことを表している。
　図６の計画書提示処理ステップＳ２０７では、各グループＧｒの代表故障モードをまとめたものを、検証対象の故障モードとして、ユーザーに提示する。これが図１の代表評価対象故障データＤ４である。
　図１１に、代表評価対象故障データＤ４の提示方法の例を示す。図１１は、モニタ画面に表示する形式での提示例を示している。モニタ画面９０の上段には保全業務関係の業務検証項目が、グループ、コンポーネントＤ１１、ＩＤ番号Ｄ１３、故障モードＤ１４、代表度、検査手段Ｄ１５、保全手段Ｄ１６、要求スキルＤ１７の各データの一覧形式として提示されている。同様に、モニタ画面９０の下段には保全ＩＴ関係の業務検証項目が、グループ、コンポーネントＤ１１、ＩＤ番号Ｄ１３、故障モードＤ１４、代表度、検査手段Ｄ１５、保全手段Ｄ１６、要求スキルＤ１７の各データの一覧形式として提示されている。
　モニタ画面９０の上下に示す分割画面９１、９２において、グループの欄を指定する操作を行うと、グループ内項目選択画面３００００が選択表示される。グループ内項目選択画面３００００には、当該グループに属するが、代表事例には選択されなかった他の事例が纏めて表示される。このグループ内項目選択画面３００００において、他の事例を選択すると、代表事例を変更することができる。計算機が推奨した事例に対して、ユーザーＭが他の事例の方が適切であると判断した場合などに代表事例を入れ替えることが可能である。
　分割画面９１、９２内には、さらに閾値調整画面３１０００が準備されている。業務検証に関する距離閾値ＤＴＡＬ、ＩＴ検証に関する距離閾値ＤＴＢＬを可変に設定変更することにより、図１１のモニタ画面９０に表示されるグループ分けの観点が変更され、新たな観点でのグループ分けによる、図１の代表評価対象故障データＤ４を提示可能である。この部分の処理内容が、図６の処理ステップＳ２０８に示されている。
　計算機が推奨した事例の提示を受け入れ、あるいは変更した事例を承認する場合にはユーザーＭは、承認画面３３０００により、提示内容の承認を行う。
　この際ユーザーＭには、代表度が高い故障モードから順に提示して、検証実施上適切なものを選択させることが可能である。あるいは、グループごとにひとつだけではなく、ユーザーが評価実施可能と判断すれば、複数を選択してもよい。複数の項目で評価を実施することで、評価の精度が向上する効果が見込まれる。検証が容易であると判明している故障モードを選択することで、作業を容易に進めることも可能である。また、そのグループの業務・ＩＴ要件の評価が不要である場合は、すべて選択しないということも可能とする。
　なお図１１においては、上段、下段にそれぞれ業務向け、ＩＴ向けの検証項目を並べており、それぞれ、グループごとの代表故障モードを表示している。また、グループ欄のプルダウンボタンをクリックすることで、そのグループ内の全故障モードのリストを提示し、評価対象とする故障モードを選択可能としている。
　また抽出された代表故障モードの数が非常に多く、検証実施が困難であると思われる場合は、図６のグループ分割調整処理ステップＳ２０８において、距離閾値ＤＴＡＬまたはＤＴＢＬを大きくして、故障モードグループ化処理ステップＳ２０２を再実行することで生成されるグループ数を少なくする。あるいは抽出された故障モード数が少なすぎると思われる場合は、距離閾値ＤＴＡＬまたはＤＴＢＬを小さくすることで、生成されるグループ数を大きくすることができる。
　図１１においては、距離閾値ＤＴＡＬまたはＤＴＢＬを閾値調整画面３１０００で変化させ、更新ボタン押下によりリスト内容を距離閾値により更新することで、調整可能としている。
　また、距離閾値を調節する別の方法として、業務・ＩＴごとにひとつの距離閾値を持つのではなく、クラスタリング結果から、部分ごとにどの階層でグループを生成するか、選択させる方法も考えられる。
　図１２にその場合の業務向けクラスタリング結果のユーザー提示画面例９３を示す。モニタ画面例９３では、図７、図８の関係を図示表示し、決定釦１０００によりユーザーＭの決定とする。この場合、グループ生成の階層選択を行うアイコン３５０００をグラフ上で追加・削除・移動させることで、グループ生成を行い、例では６個のグループが生成されている。
　また、少数の故障モードに対する検証で、評価全体を完了させられるように、業務に関する評価対象の故障モードと、ＩＴに関する評価対象の故障モードを、できる限り重複させるように選ぶことが考えられる。この場合例えば、各故障モードに付与された業務・ＩＴそれぞれでの代表度の合計が小さいものから順に、業務・ＩＴそれぞれで対応する故障モードのグループを重複無く代表するように抽出して、重複無く抽出することが不可能になった段階で、代表が抽出されていないグループにそれぞれから、もっとも代表度が高いものを抽出し、それをユーザーに提示すると言う方法が考えられる。
　最終的に、ユーザーが提示された評価対象故障モードに納得し、確認ボタンを押下することで、評価対象となる故障モードが確定する。ユーザーにはこの時点で提示されていた故障モードの一覧が、画面表示、プリントアウトなどの方法で引き渡される。
　このとき、業務向け、ＩＴ向けそれぞれの評価対象故障モードが重複している可能性があるので、重複を排除した表をユーザーに提示することで、重複作業の記載を含まない、作業計画として適切な表示とする。
　表示例を図１３に示す。図１３の評価対象故障モード一覧表示例では、図１１の表示内容（コンポーネントＤ１１、ＩＤ番号Ｄ１３、故障モードＤ１４、代表度、検査手段Ｄ１５、保全手段Ｄ１６、要求スキルＤ１７の各データ）に加えて、代表度、業務検証Ｄ１８、ＩＴ検証Ｄ１９の各データも併せて表示可能としている。さらには、保全作業に対応して保全結果を表示可能としておくのがよい。なお確認釦３４０００は、承認と否決の確認をできるものを準備するのがよい。以上により、図１の評価計画ユニットＵ２での処理は完了する。
　図１において、評価計画Ｄ４（代表評価対象故障）を受領したユーザーＭは、計画対象の故障モードに対して、定期検査や診断技術利用の保全を実際に実施した際に、保全業務に必要な人的リソース（人×ｈｏｕｒ）や業務上のスキル、診断ＩＴ技術利用のために必要な通信容量、ストレージ容量、ＣＰＵ時間などのＩＴリソースなどの要件を、技術適用試験あるいはコンピュータシミュレーション、机上検討などから測定する。
　測定結果が図１の評価結果データＤ５である。測定結果データＤ５の例を図１４に示す。図１４の測定結果データＤ５の例では、計算機が推奨してユーザーＭが承認した事例（コンポーネントＤ１１、ＩＤ場番号Ｄ１３、故障モードＤ１４で特定）ごとに、ユーザーＭによる検証結果の情報が付与されている。検証結果の情報は、業務要件についての検証結果（業務要件検証結果）Ｄ５ＡとＩＴ要件についての検証結果（ＩＴ要件検証結果）Ｄ５Ｂに大別されている。業務要件検証結果Ｄ５Ａは、さらに検査業務についての検証結果（検査業務検証結果）Ｄ５Ａ１と保全業務についての検証結果（保全業務検証結果）Ｄ５Ａ２として個別に把握されている。なお、ＩＴ要件検証結果Ｄ５Ｂ、検査業務検証結果Ｄ５Ａ１、保全業務検証結果Ｄ５Ａ２はさらに定量要件（Ｄ５Ａ１１、Ｄ５Ａ２１、Ｄ５Ｂ１）と定性要件（Ｄ５Ａ１２、Ｄ５Ａ２２、Ｄ５Ｂ２）に区分されて記載されている。この評価結果データＤ５は、ＨＭＩを通じて、保全設計支援システム１００に入力される。
　次に図１の、要求リソース推定ユニットＵ３では、作成済みの故障モードグループと、ユーザーによる代表故障に対する要件測定結果から、保全全体に対する保全業務・ＩＴ要件を推定する。図１５に要求リソース推定ユニットＵ３における処理フローを示す。
　要求リソース推定ユニットＵ３における処理フローが、処置ステップＳ３００での判断により開始されると、はじめに、評価結果・故障モードグループ読み込み処理ステップＳ３０１において、先に計算機により生成された故障モードグループのデータ（図７、８、９、１０に一例を示す）と、ユーザーＭにより作成された評価結果データＤ５を読み込む。
　次に、評価された要件の種類ごとに、それらの結果を、処理ステップＳ３０２と処理ステップＳ３０８の間での繰り返し処理（大枠繰り返し処理）により、ループで順次処理する。この処理ステップＳ３０２と処理ステップＳ３０８の間での大枠繰り返し処理の内部では、さらに処理ステップＳ３０３と処理ステップＳ３０７の間での繰り返し処理（小枠繰り返し処理）を実行する。内部での小枠繰り返し処理は、故障モードグループごとに実行されている。
　かくして図１４に示した繰り返し処理によれば、大枠繰り返し処理において、図１４に例示した検査業務の定量・定性要件Ｄ５Ａ１１、Ｄ５Ａ１２、保全業務の定量・定性要件Ｄ５Ａ２１、Ｄ５Ａ２２、ＩＴの定量・定性要件Ｄ５Ｂ１、Ｄ５Ｂ２のそれぞれに対して繰り返し処理が行われる。また大枠繰り返し処理では、ＩＴ定量要件のように、通信・ストレージ・計算量要求などの詳細に分けられている場合は、それぞれに対してさらに実行されるものとする。さらに、それぞれの要件で、小枠繰り返し処理においては故障モードの種類ごとにループ処理を行う。
　以上の繰り返し処理の中では、まず妥当性確認処理ステップＳ３０４において、故障モードグループ内で、複数の検証項目を設定した場合に、検証項目間で結果に矛盾や不整合が無いかを、妥当性判定知識データベースＤＢ２内の妥当性判定知識データＤ２と比較検証することから確認する。
　妥当性判定知識データＤ２は、連続番号Ｄ２１ごとに、関連する要件種類Ｄ２２と、評価結果が非妥当であると判定する条件Ｄ２３を含んでおり、図１６にその例を示す。図１６に示すように、非妥当と判断した理由をユーザーに提示するための、理由説明のデータＤ２４を含んでいても良い。
　妥当性判定知識データＤ２の一例を示すと、連続番号Ｄ２１が「１」の事例として、関連する要件種類Ｄ２２が「業務要件・検査」であり、非妥当判断条件Ｄ２３が「異なるスキル要求の混在」であるとき、非妥当と判断した理由Ｄ２４には「別スキル保有の作業員派遣が必要」が知識として記憶されている。また、連続番号Ｄ２１が「２」の事例として、関連する要件種類Ｄ２２が「ＩＴ要件・通信」であり、非妥当判断条件Ｄ２３が「通信速度要求５０ｋｂｐｓ以上と未満の混在」であるとき、非妥当と判断した理由Ｄ２４には「５０ｋｂｐｓ以上の場合Ｗｉｆｉ必須。５０ｋｂｐｓ未満の場合Ｂｌｕｅｔｏｏｔｈ(登録商標)可」が知識として記憶されている。
　例えば図１４の評価結果例（評価結果データＤ５）の場合、ＩＴ要件の評価項目として、Ｇｒ４から、故障モードのＩＤ番号がＩＤ８の事例、「軸受けベアリングのベアリング傷・磨耗」と、ＩＤ番号がＩＤ９の事例「軸受けベアリングのグリス劣化」についての検査、評価がユーザーＭにより実施されて、計算機である保全設計支援システム１００に評価結果が提示されているが、評価の結果、この２つは通信要求が大きく異なり、ＩＤ８は５ｋｂｐｓ、ＩＤ９は１００Ｋｂｐｓとなっている。
　この場合、図１６の連続番号Ｄ２１が「２」の事例が該当している。妥当性判定知識Ｄ２の連続番号Ｄ２１が「２」の事例では、通信速度要求５０ｋｂｐｓ以上と未満の混在を定義しており、別々の通信手段が必要となっている。このため、ＩＤ８とＩＤ９の事例の２つの故障モードに対しては、類似のＩＴ要件を適用できないと判断される。
　この場合、故障モードのグループわけが不適切であったと判断されるため、図１５のグループ再分割処理ステップＳ３０５において、ユーザーＭに対して、ＩＴ要件のグループＧｒ４を分割し、それぞれに関連する故障モードを別々のグループに分類しなおすように依頼する。
　この際のユーザー提示画面としては、故障モードリストにグループを直接入力させても、図１２に示したようなクラスタ図による入力手段を用いることで、グループ分類をサポートしつつ、分類を作り直すこととしても良い。また、図１の評価計画ユニットＵ２の処理に戻り、グループ生成条件の距離閾値を調整し、検証項目を再選定しても良い。ここでは、ＩＤ番号がＩＤ８の内容に要件が近い故障モードを、Ｇｒ４－Ａ、ＩＤ番号がＩＤ９の内容に要件が近い故障モードをＧｒ４－Ｂとして、ユーザーＭが再定義したものとする。
　次に図１５の要件割り当て処理ステップＳ３０６では、業務・ＩＴ要件それぞれで、同じグループ内に存在している故障モードは、同じ要件を持つとして、各故障モードに代表検証項目で調査された要件の定量・定性要件を割り当てる。
　ただし、ひとつのグループから複数の検証が実施されている場合は、定量要件は値の平均をとり、定性要件は重複なくすべての要件を合わせて列挙することとする。また作業量については、業務実施周期や頻度を元に、年単位の平均業務量要求に変換し、それを要求人数として、提示することとする。
　図１７に要件割り当て結果の例を示す。図１７の横軸項目は、基本的には図１４の評価結果例の表示フォーマットに準拠しているが、新たにグループの欄Ｄ５Ａ０、Ｄ５Ｂ０を追加している。Ｄ５Ａ０は業務要件検証結果Ｄ５Ａにおけるグループを定義しており、Ｄ５Ｂ０はＩＴ検証結果Ｄ５Ｂにおけるグループを定義している。ここでグループとは、図７から図１０で例示したところのグループであり、図１５のグループ再分割処理ステップＳ３０５におけるグループの再構成により定義されたグループである。
　業務要件検証結果Ｄ５Ａについてのグループ定義によれば、図１４の評価結果例のＩＤ番号１はグループＧｒ２、ＩＤ番号２はグループＧｒ３、ＩＤ番号７はグループＧｒ７、ＩＤ番号８、１０、１３はグループＧｒ５、ＩＤ番号９はグループＧｒ６、ＩＤ番号２３はグループＧｒ１、ＩＤ番号２４はグループＧｒ４である。
　また業務要件検証結果Ｄ５Ａについて、グループの欄Ｄ５Ａ０、Ｄ５Ｂ０において背景色を付しているＩＤ番号（１、２、７－９、１３、２３、２４）のものは、図１４の評価結果例の表示フォーマットに記載の案件（既出案件）であるが、グループの欄Ｄ５Ａ０、Ｄ５Ｂ０において背景色を付していないＩＤ番号（３、５、１５、１９）のものは、要件割り当てにより新規に追加された案件（新規案件）である。
　例えばグループＧｒ２に分類されるＩＤ番号３、５の新規案件は、同じグループＧｒ２に分類されるＩＤ番号１の既出案件の要件割り当てにより、ＩＤ番号１の妥当性検証が不十分であるという理由で、新たに追加することを要求された案件である。同様に、グループＧｒ５に分類されるＩＤ番号１５の新規案件は、同じグループＧｒ５に分類されるＩＤ番号８、１０、１３の既出案件の要件割り当てにより、ＩＤ番号８、１０、１３の妥当性検証が不十分であるという理由で、新たに追加することを要求された案件である。グループＧｒ６に分類されるＩＤ番号１９の新規案件は、同じグループＧｒ６に分類されるＩＤ番号９の既出案件の要件割り当てにより、ＩＤ番号９の妥当性検証が不十分であるという理由で、新たに追加することを要求された案件である。
　なお上記処理は、業務要件検証結果Ｄ５Ａの場合を例示したが、同様のことはＩＴ検証結果Ｄ５Ｂでも行われるので、ここでの説明を割愛する。
　次に、要件生成処理ステップＳ３０９では、要件定義知識データベースＤＢ３に記憶された要件定義知識Ｄ３を用いて、付加的な要件の追加を行う。図１８に要件定義知識Ｄ３の例を示す。図１８の要件定義知識Ｄ３は、連続番号Ｄ３１、条件Ｄ３２、付加要件Ｄ３３から構成されている。
要件生成処理Ｓ３０９の処理では、要件定義知識Ｄ３中の条件Ｄ３２と、要件割り当て結果を比較して、該当項目があれば、付加要件として抽出する。
　例えば、ＩＴ検証結果Ｄ５ＢのＩＤ番号７－１０、１３、１５、１９について、これらにおける通信がＷｉｆｉあるいはＢｌｕｅｔｏｏｔｈであることを、図１８の付加要件Ｄ３３から抽出してＩＴ検証結果Ｄ５Ｂの定性要件Ｄ５Ｂ２に追記するなどの処理を行う。
　要件生成処理ステップＳ３０９では、ここまでの処理で全故障モードに割り当てられた、業務・ＩＴ要件を総合して、対象アセットの保全全体での業務・ＩＴ要件（要件・リソース見積りＤ６）を生成する。この際に、作業量やストレージ、ＣＰＵ計算量要件などの定量要件はそれぞれ合計されて、ユーザーに提示される。また作業量については、業務実施周期や頻度を元に、年単位の平均業務量要求に変換し、それを要求人数として、提示することとする。定性要件は、項目を重複無い様に集約し、ユーザーに提示する。
　図１９に要件・リソース見積りＤ６の提示例を示す。この場合の横軸項目は、業務要件Ｄ６Ａ、ＩＴ要件Ｄ６Ｂ、業務要件合計Ｄ６Ｃ、付加要件Ｄ６Ｄであり、業務要件Ｄ６Ａはさらに検査業務要件Ｄ６Ａ１、保全業務要件Ｄ６Ａ２に細分される。また検査業務要件Ｄ６Ａ１、保全業務要件Ｄ６Ａ２、ＩＴ要件Ｄ６Ｂ、業務要件合計Ｄ６Ｃはそれぞれが定量要件（Ｄ６Ａ１１、Ｄ６Ａ２１、Ｄ６Ｂ１、Ｄ６Ｃ１）と定性要件（Ｄ６Ａ１２、Ｄ６Ａ２、Ｄ６Ｂ２、Ｄ６Ｃ２）に分けて記述されている。
　また、全体を合計して表示するのではなく、コンポーネントごとに合計して提示することで、業務・ＩＴシステム上の要件が重く、ボトルネックとなるコンポーネントを抽出することで、保全業務改善を促すことも可能である。
　最終的に要件生成結果（要件・リソース見積りＤ６）を、ＨＭＩを通じてユーザーＭに提示する。
　以上の処理により、必要最小限の故障モードに対する、業務・ＩＴ要件の検証実施により、対象アセット全体の保全作業・ＩＴ要件の推定を行う、保全設計支援システムが実現する。
１００：保全設計支援システム，ＤＢ１：アセット知識データベース，ＤＢ２：妥当性判定知識データベース，ＤＢ３：要件定義知識データベース，Ｄ１：アセット知識，Ｄ２：妥当性判定知識，Ｄ３：要件定義知識，Ｄ４：代表評価対象故障，Ｄ５：評価結果，Ｄ６：要件・リソース見積もり，Ｍ：評価実施者，Ｕ１：故障類似度推定ユニット，Ｕ２：評価計画ユニット，Ｕ３：要求リソース推定ユニット

Claims (17)

  1. 　アセットにおける評価対象故障をユーザーに提示する保全設計支援システムであって、
    　入出力部を備えたＨＭＩと、前記アセットの構造、故障、保全内容についてのアセット知識を記憶するアセット知識データベースと、前記アセット知識を用いて前記アセットの故障モード間の類似度を算出する故障類似度推定ユニットと、類似の故障モードの中から評価対象とする代表の故障モードを抽出し、前記ＨＭＩを介してユーザーに評価計画として提示する評価計画ユニットを備えることを特徴とする保全設計支援システム。
  2. 　請求項１記載の保全設計支援システムであって、
    　前記評価計画ユニットは、前記アセットの故障モードから、代表的な保全要件を持つと推定される少数の故障モードを抽出して、前記評価計画としてユーザーに提示することを特徴とする保全設計支援システム。
  3. 　請求項１または請求項２に記載の保全設計支援システムであって、
    　前記故障類似度推定ユニットは、前記アセットの故障モード間の類似度を、前記アセット知識の項目間の距離として推定し、
    　前記評価計画ユニットは、前記距離が近い故障モードを距離閾値に基づいてグループ化し、グループごとに代表の故障モードを抽出し、抽出結果をユーザーに前記評価計画として提示することを特徴とする保全設計支援システム。
  4. 　請求項３記載の保全設計支援システムであって、
    　前記故障モードをグループ化する際の前記距離閾値をユーザーが調節可能とすることで、ユーザーが妥当と考える代表の故障モードが抽出された前記評価計画を生成することを特徴とする保全設計支援システム。
  5. 　請求項３記載の保全設計支援システムであって、
    　項目間の距離の算出対象となる前記アセット知識の項目として、前記故障モードに対応するコンポーネントの構造上の距離を、構造展開ツリー上の距離として算出し、故障内容と保全実施内容間の距離を、記述文章の単語不一致比率として算出することを特徴とする保全設計支援システム。
  6. 　請求項３記載の保全設計支援システムであって、
    　前記アセット知識の項目ごとに算出された距離を、保全上の要件ごとに異なる総合距離に重み付けして集約することで、要件の種類ごとに、近い要件内容を持った故障モードのグループ化を要件の種類ごとに別々に実施することを特徴とする保全設計支援システム。
  7. 　請求項６記載の保全設計支援システムであって、
    　要件ごとに別々に生成された故障モードのグループから、評価対象となる代表の故障モードを選ぶ際に、選択された故障モードが、最小の数によって、複数の要件ごとの故障モードのグループを代表するように選ぶことで、最小の評価件数で、すべてのグループにおいて代表故障モードの評価を実現することを特徴する保全設計支援システム。
  8. 　請求項３記載の保全設計支援システムであって、
    　おのおののグループから代表故障モードを選択する方法として、各グループ内で、ある故障モードから他のすべての故障モードへの距離の和がもっとも小さい故障モードを代表として選択することを特徴とする保全設計支援システム。
  9. 　請求項１から請求項８のいずれか１項に記載の保全設計支援システムであって、
    　前記ＨＭＩを介してユーザーに提示した評価計画に従ってユーザーが実行した評価結果を、前記ＨＭＩを介して取り込むことを特徴とする保全設計支援システム。
  10. 　請求項９記載の保全設計支援システムであって、
    　ユーザーが代表の故障モードに対して実施した保全要件の前記評価結果を用いてアセット全体の保全要件を生成する要求リソース推定ユニットを備え、
    　前記要求リソース推定ユニットは、前記評価結果からアセット全体の保全要件を推定し、最小限の評価で精度の高い要件策定を行うことを特徴とする保全設計支援システム。
  11. 　請求項１０に記載の保全設計支援システムであって、
    　ユーザーが実施した代表故障モードに対する保全要件の評価結果の妥当性を検証するために必要な妥当性判定知識を保存する妥当性判定知識データベースを備え、
    　前記要求リソース推定ユニットは、前記妥当性判定知識を参照して前記評価結果が妥当でない場合はユーザーに提示し、評価計画の修正を可能とすることで、精度の高い保全要件策定を可能とすることを特徴とする保全設計支援システム。
  12. 　請求項１０または請求項１１に記載の保全設計支援システムであって、
    　前記アセット知識とユーザーが実施した代表の故障モードに対する保全要件についての前記評価結果から、付加的な保全要件を追加するための条件と付加内容を表す要件定義知識を保存する要件定義知識データベースを備え、
    　前記要求リソース推定ユニットは、前記要件定義知識と前記アセット知識と前記評価結果から付加的な保全要件を追加することを特徴とする保全設計支援システム。
  13. 　請求項１０から請求項１２のいずれか１項に記載の保全設計支援システムであって、
    　保全の業務実施上の要求作業量と人員数を推定することを特徴とする保全設計支援システム。
  14. 　請求項１０から請求項１３のいずれか１項に記載の保全設計支援システムであって、
    　保全で利用されるＩＴシステムのリソース要件として、要求される通信要領とデータ保全するストレージ容量と、要求される計算量を推定することを特徴とする保全設計支援システム。
  15. 　請求項１０から請求項１４のいずれか１項に記載の保全設計支援システムであって、
    　前記要求リソース推定ユニットにおいて、提示した評価計画に基づいた評価結果から、対象アセット全体の保全要件を推定する方法として、ある評価対象の故障モードが代表していると考えられる故障モードのグループ内では、評価対象となった故障モードと類似の保全要件を持つとし、グループ内全体での保全要件を、グループ内すべての故障モードの保全要件の総和とし、これをすべての評価対象故障モードに対して実施することで、アセット全体の保全要件を推定することを特徴する保全設計支援システム。
  16. 　請求項１２に記載の保全設計支援システムであって、
    　前記要求リソース推定ユニットにおいて、ひとつの故障モードのグループから、複数の評価対象となる代表の故障モードがある場合、代表の故障モード間の保全要件の評価結果が類似の結果と判定できるか判定する条件を記載した妥当性判定知識を備え、結果が類似でないと判定された場合は、グループの作成方法あるいは代表の故障モードの選択に問題があるとして、グループの生成と代表の選択を再実行するようにユーザーに促し、また、評価計画ユニットにおけるグループと代表故障モードの修正を可能とすることを特徴とする保全設計支援システム。
  17. 　請求項１４に記載の保全設計支援システムであって、
    　前記要求リソース推定ユニットにおいて、評価実施によって得られた保全要件以外の、保全業務またはＩＴ構築上の付加要件がある場合、評価結果あるいはアセット知識から、付加要件を設定するための条件を記載した、要件定義知識を用いることを特徴とした保全設計支援システム。
PCT/JP2017/046905 2017-12-27 2017-12-27 保全設計支援システム WO2019130469A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2017/046905 WO2019130469A1 (ja) 2017-12-27 2017-12-27 保全設計支援システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2017/046905 WO2019130469A1 (ja) 2017-12-27 2017-12-27 保全設計支援システム

Publications (1)

Publication Number Publication Date
WO2019130469A1 true WO2019130469A1 (ja) 2019-07-04

Family

ID=67066903

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/046905 WO2019130469A1 (ja) 2017-12-27 2017-12-27 保全設計支援システム

Country Status (1)

Country Link
WO (1) WO2019130469A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021005861A1 (ja) * 2019-07-10 2021-01-14 株式会社日立製作所 故障箇所特定支援システム
WO2023044632A1 (zh) * 2021-09-22 2023-03-30 西门子股份公司 工业设备维护策略生成方法、装置、电子设备和存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002123314A (ja) * 2000-10-12 2002-04-26 Chiyoda Corp 設備保全の最適化システム
JP2008191900A (ja) * 2007-02-05 2008-08-21 Toshiba Corp プラントの信頼性重視保全運用支援システム及び運用支援方法
WO2016147657A1 (ja) * 2015-03-17 2016-09-22 日本電気株式会社 情報処理装置、情報処理方法、及び、記録媒体
JP2017146674A (ja) * 2016-02-15 2017-08-24 一般財団法人電力中央研究所 分類装置、分類方法および分類プログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002123314A (ja) * 2000-10-12 2002-04-26 Chiyoda Corp 設備保全の最適化システム
JP2008191900A (ja) * 2007-02-05 2008-08-21 Toshiba Corp プラントの信頼性重視保全運用支援システム及び運用支援方法
WO2016147657A1 (ja) * 2015-03-17 2016-09-22 日本電気株式会社 情報処理装置、情報処理方法、及び、記録媒体
JP2017146674A (ja) * 2016-02-15 2017-08-24 一般財団法人電力中央研究所 分類装置、分類方法および分類プログラム

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021005861A1 (ja) * 2019-07-10 2021-01-14 株式会社日立製作所 故障箇所特定支援システム
JP2021015328A (ja) * 2019-07-10 2021-02-12 株式会社日立製作所 故障箇所特定支援システム
JP7430040B2 (ja) 2019-07-10 2024-02-09 株式会社日立製作所 故障箇所特定支援システム
WO2023044632A1 (zh) * 2021-09-22 2023-03-30 西门子股份公司 工业设备维护策略生成方法、装置、电子设备和存储介质

Similar Documents

Publication Publication Date Title
CN108375715B (zh) 一种配电网线路故障风险日预测方法及系统
CN105809255B (zh) 一种基于物联网的火电厂旋转机械健康管理方法及系统
JP4875661B2 (ja) 航空機の健全性診断装置及び方法並びにプログラム
US8688405B2 (en) Remote monitoring systems and methods
JP5695998B2 (ja) 保守支援システム、保守支援装置および保守支援プログラム
CN107545095A (zh) 用于飞行器大修期间的结构修理的预测方法和系统
NO337835B1 (no) Fremgangsmåte og system for sanntidsoperasjoner og vedlikehold
CN112114579A (zh) 一种基于攻击图的工业控制系统安全度量方法
Van et al. Research trends on machine learning in construction management: a scientometric analysis
CN104820901A (zh) 基于生产现场数据的服装一线员工技能评价方法
CN106056273A (zh) 一种基于故障树的冗余电动泵本体失效可靠性监测方法
WO2019130469A1 (ja) 保全設計支援システム
Čepin Importance of human contribution within the human reliability analysis (IJS-HRA)
Azadeh et al. Selection of optimum maintenance policy using an integrated multi-criteria Taguchi modeling approach by considering resilience engineering
Cruz Evaluating record history of medical devices using association discovery and clustering techniques
Bilgin et al. A decision support system for project portfolio management in construction companies
Tena-García et al. Implementing data reduction strategies for the optimal design of renewable energy systems
Tavakoli et al. Modification of the FFTA method for calculating and analyzing the human reliability of maintenance groups in power transmission grids
Häckell A holistic evaluation concept for long-term structural health monitoring
CN115618735A (zh) 基于数字孪生的设施结构健康监测方法及相关装置
CN115600695A (zh) 一种计量设备的故障诊断方法
KR20230041345A (ko) 디지털 트윈 정보를 활용한 장비 관리 시스템
Lybeck et al. Lifecycle prognostics architecture for selected high-cost active components
Vicêncio et al. An intelligent predictive maintenance approach based on end-of-line test logfiles in the automotive industry
AHMAD et al. A Data-Driven Approach To Supplier Selection In Industrial Construction Projects

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17936043

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17936043

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP