Design support apparatus and design support method

Abstract

To carry out evaluation with less rework while reducing the number of processes and costs required to fix trouble required after discovery of the trouble and an evaluation of a risk of any trouble in a product.SOLUTION: A design support apparatus comprises: an input part for inputting required specification information including a plurality of requirement specifications for a product or a system and information indication their hierarchical structures; an antonym information generating unit for generating information indicating trouble events by generating antonym information indicating reverse meaning of the required specification; and a failure tree generating unit for generating a failure tree using the information indicating the trouble event and the information indicating the hierarchical structure.SELECTED DRAWING: Figure 1A

Description

[Technical field]

[0001] The present invention relates to an apparatus for supporting design work by generating and presenting a fault tree from required specification information of a target product or system. [Background technology]

[0002] In the design of products and systems (hereafter referred to as "products"), there is a demand for improving the performance of the target product while at the same time ensuring the reliability of the product and preventing defects during manufacturing. In particular, being able to verify the risk of defects occurring in advance in the upstream process of product design contributes to improving design efficiency and reducing time and cost losses.

[0003] Fault Tree Analysis (FTA) is one of the methods for evaluating the risk of product defects. In FTA, a quantitative evaluation of the path of defect occurrence and its risk is carried out using a diagram called a fault tree, which represents defect phenomena and their causes in a tree format.

[0004] In addition, in order to verify the risk of defects occurring in complex products, it is important to have a bird's-eye view of information such as the product's structure, functions, required specifications, etc. For example, MBSE (Model-Based Systems Engineering) is one technology that provides an overview of product-related information.

[0005] Conventionally, an invention of this type is described in Patent Document 1 (JP Patent Publication No. 2019-012316 A). Patent Document 1 describes a method of using equipment design information and equipment function hazards that represent a deterioration in the basic functions of a predefined equipment system to create a failure mode scenario tree from the failure of a component device to the equipment function hazard, calculating an index value representing the occurrence frequency using the structure of the tree, creating a risk scenario tree from the equipment mechanism hazard to the quality risk, calculating an index value indicating the severity using the structure of the tree, and determining the risk level of the equipment function hazard based on the calculated occurrence frequency and severity. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] JP 2019-012316 A Summary of the Invention [Problem to be solved by the invention]

[0007] It is necessary to evaluate the risk of product defects in a way that reduces the amount of work and costs involved in responding to the risk of defects after they are discovered, while minimizing rework.

[0008] Patent Document 1 uses equipment design information to generate a fault tree and evaluate the defect risk of a product system, but this equipment design information is obtained at the basic design and detailed design stages, and a method for evaluating product defect risks at a more upstream stage is desirable. [Means for solving the problem]

[0009] In order to achieve the above-mentioned object, the present invention provides a design support device that includes an input unit for inputting requirement specification information including a plurality of requirement specifications for a product or system and information indicating their hierarchical structure, an antonym information generation unit that creates information indicating a malfunction phenomenon by generating antonym information that has an opposite meaning to the requirement specifications, and a fault tree generation unit that generates a fault tree using the information indicating the malfunction phenomenon and the information indicating the hierarchical structure. Effect of the Invention

[0010] According to this invention, it is possible to automatically generate a fault tree from the requirement specification information defined in the requirement definition stage, which is an upstream process of product design, and the hierarchical structure of the requirement specification. By using the generated fault tree to perform FTA, it is possible to evaluate the risk of defects that a product has.

[0011] In addition, because the risk of defects is evaluated at the requirements definition stage, it is possible to keep verification costs and the costs of correcting defects when they are discovered lower.

[0012] Problems, configurations and effects other than those described above will become apparent from the following description of the preferred embodiment of the invention. [Brief description of the drawings]

[0013] [Figure 1A] 1 is a block diagram of a design support device according to a first embodiment. [Figure 1B] 2 is a process flowchart according to the first embodiment. [Figure 2A] 1 is an example of a modeling language for requirement specification information. [Figure 2B] This is an example of visualizing required specification information. [Diagram 3] 4 is a diagram illustrating a process of an opposite meaning information generating unit according to the first embodiment. FIG. [Figure 4] 11 is a flowchart of an opposite meaning information generating unit according to the first embodiment. [Diagram 5] FIG. 4 is a diagram illustrating a process of a fault tree generator according to the first embodiment. [Figure 6] 11 is a flowchart of a fault tree generating unit according to the first embodiment. [Figure 7A] 13 is an example of a fault tree generation process that takes into account expansion requirements. [Figure 7B] 13 is an example of a fault tree generation process that takes into account expansion requirements. [Figure 8A] FIG. 11 is a block diagram of a design support device according to a second embodiment. [Figure 8B] 11 is a process flowchart according to the second embodiment. [Figure 9] 13 is an example of a terminal event storage unit according to the second embodiment. [Figure 10] 13 is a diagram illustrating a process of an end event acquisition unit according to the second embodiment. FIG. [Figure 11] 13 is a flowchart of an end event acquiring unit according to the second embodiment. [Figure 12] 13 is an example of a display screen according to the second embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. The embodiment is an example for explaining the present invention, and appropriate omissions and simplifications are made for clarity of explanation. The present invention can be implemented in various other forms. Unless otherwise specified, each component may be singular or plural.

[0015] In order to facilitate understanding of the invention, the position, size, shape, range, etc. of each component shown in the drawings may not represent the actual position, size, shape, range, etc. Therefore, the present invention is not necessarily limited to the position, size, shape, range, etc. disclosed in the drawings.

[0016] As examples of various information, the various information may be described using expressions such as "table" and "list", but the various information may be expressed using data structures other than these. For example, various information such as "XX table" and "XX list" may be expressed as "XX information". When describing identification information, expressions such as "identification information", "identifier", "name", "ID", and "number" are used, but these are mutually interchangeable.

[0017] When there are multiple components having the same or similar functions, they may be described by using the same reference numerals with different subscripts, or when there is no need to distinguish between these multiple components, the subscripts may be omitted.

[0018] In the embodiments, a process performed by executing a program may be described. Here, a computer executes the program using a processor (e.g., CPU, GPU), and performs the process defined by the program while using a storage resource (e.g., memory) and an interface device (e.g., communication port), etc. Therefore, the subject of the process performed by executing the program may be the processor. Similarly, the subject of the process performed by executing the program may be a controller, device, system, computer, or node having a processor. The subject of the process performed by executing the program may be a calculation unit, and may include a dedicated circuit that performs specific processing. Here, the dedicated circuit is, for example, an FPGA (Field Programmable Gate Array), an ASIC (Application Specific Integrated Circuit), or a CPLD (Complex Programmable Logic Device), etc.

[0019] The program may be installed in the computer from a program source. The program source may be, for example, a program distribution server or a computer-readable storage medium. When the program source is a program distribution server, the program distribution server may include a processor and a storage resource that stores the program to be distributed, and the processor of the program distribution server may distribute the program to be distributed to other computers. In addition, in the embodiment, two or more programs may be realized as one program, and one program may be realized as two or more programs. EXAMPLES

[0020] FIG. 1A is a block diagram of a design support device 100 according to a first embodiment of the present invention, which is realized by a general computer and includes a central processing unit (CPU) 101 that performs calculation processing, an input device 102 such as a keyboard or a mouse, an output device 103 such as a display device, a main memory device 110, and an auxiliary memory device 120.

[0021] The main memory device 110 includes an input unit 111, an antonym information generating unit 112, and a fault tree generating unit 113, which are all programs. Hereinafter, when an entity is described as "XX unit", it means that the central control device 101 reads each program from the main memory device 110 and realizes the function of each program (described in detail later) on the main memory device.

[0022] The auxiliary storage device 120 has a requirement specification information database (DB) 121 in which requirement specifications of a device to be designed, etc. are stored. The requirement specification information DB 121 may be provided outside the design support device 100.

[0023] FIG. 1B is a diagram showing a processing flow according to the first embodiment of the present invention.

[0024] First, in step S140, the input unit 111 acquires requirement information written in a modeling language from the requirement information DB 121 or from an external source. The requirement information stores requirement specifications for a product and a system and information indicating their hierarchical structure.

[0025] Next, in step S141, the antonym information generation unit 112 extracts the content of the required specification described as the required specification from the required specification information acquired by the input unit 111, and generates antonym information having the opposite meaning to the content of the extracted required specification.

[0026] To generate antonym information, we use natural language processing technology. Natural language processing refers to technology that processes language written in natural language by machine to extract or process content, and is used in search engines and predictive text conversion. Natural language processing also makes it possible to recognize the structure of a document, the relationships between words, and the meaning of a document.

[0027] Next, in step S142, the fault tree generation unit 113 uses the hierarchical structure of the requirement specification information input to the input unit 111 and the antonym information generated by the antonym information generation unit 112 to generate a fault tree having a structure similar to the hierarchical structure of the requirement specification information.

[0028] Then, in step S143, the obtained fault tree information and the like are displayed on the output device 103, thereby making it possible to alert the user in advance.

[0029] The above is an overview of the overall process, and each step will be described in detail below.

[0030] 2A shows an example of a script 200 of requirement specification information written in a modeling language. Here, the script is written in Unified Modeling Language (UML), a modeling language that is widely used. Modeling languages ​​such as UML contain statements (210, 220) that define blocks to be displayed in a system model, and statements (230) that indicate the connection relationships (hierarchical information) between the blocks.

[0031] FIG. 2B shows an example of the required specification information script 200 shown in FIG. 2A visualized as a system model 200B. Here, as required specification information, an overview of the required specifications (241, 251) and details of the required specifications (242, 252) are described separately and listed together in one block (240, 250), but both may be described together in one block. Also, there are cases where an extension request (stereotype) showing in detail the relationship between the required specification blocks is described (in FIG. 2B, the " <derivereqt>The system model 200B may be generated by the central control device 101 from the required specification information 200, or may be stored together with the required specification information 200 in the required specification information DB 121.

[0032] Next, the antonym information generation process (step S141) in Fig. 1B will be described in detail with reference to Fig. 3 and Fig. 4. In the antonym information generation process, antonym information having an opposite meaning is generated from a document of required specification information expressed in a modeling language by the antonym information generation unit 112. Fig. 3 is a schematic diagram of the antonym information generation process for the script portion 210 relating to "start cruise control" in the required specification information, and Fig. 4 is a flowchart of the entire antonym information generation process.

[0033] First, in step S401, one sentence is obtained from the sentences (210, 220) that define the content of the required specification included in the required specification information (FIG. 2A) in the modeling language obtained in step S140 in FIG. 1B. In this example, the sentence indicated by reference numeral 210, "Start cruise control," is obtained by searching from the top of the required specification information 200, but it is also possible to search from the end and obtain the sentence indicated by reference numeral 220 first.

[0034] In the requirement specification information 200, a unique name is given to each sentence (block), and can be used as an ID for identifying the sentence (requirement specification block) to be processed in the following steps. For example, in the sentence 210, "StartCruiseControl" is the corresponding name.

[0035] Next, in step S402, the words and phrases contained in the sentence obtained in step S401 are classified into parts of speech. When classifying the words and phrases, a morphological analysis technique in the field of natural language processing is used. This makes it possible to identify the parts of speech of the words and phrases contained in the sentence of the requirement specification (reference numeral 310 in FIG. 3).

[0036] Next, in step S403, a syntax analysis, which is one type of natural language processing, is performed to recognize the dependency relationships between the words classified in step S402 (reference numeral 320 in FIG. 3). However, in a sentence written in natural language, the dependency relationships between words may not be uniquely determined, and in that case ("No" in step S403A), a semantic analysis of natural language processing is performed in step S404 to identify the dependency relationships between the words.

[0037] Next, in step S405, a phrase having an opposite meaning to the sentence in the requirement specification block is generated (reference numeral 330 in FIG. 3). However, the generation of a phrase having an opposite meaning is performed only for the predicate of the entire content of the sentence in the requirement specification block. This is to prevent unnecessary information conversion for proper nouns, etc. included in the content of the requirement specification information.

[0038] In addition, when generating a phrase with an opposite meaning, vectorization of words, which is a part of natural language processing, may be utilized. A phrase with an opposite meaning to the predicate is generated by inferring a word that has an opposite vector to the vector for the predicate word. At this time, a dictionary of frequently appearing phrases in the requirement specification information document or antonyms for the content of a specific predicate may be stored in advance.

[0039] Also, depending on the sentence expression of the requirement specification block, a word having a negative meaning or a word having an impossible meaning may be generated instead of a word having an opposite meaning.

[0040] Then, in step S406, the word having the opposite meaning generated in step S405 is replaced with the word in the original sentence to generate antonym information, and the information is saved in association with the name of the required specification obtained in step S401 ("StartCruiseControl" in sentence 210).

[0041] Finally, in step S407, it is determined whether processing has been performed for all the sentences in the requirement specification blocks included in the requirement specification information acquired by the input unit 101. If processing has not been performed (step S407: No), the process proceeds to step S401 to process the content of the next requirement specification. In this example, processing is performed for the requirement specification block 220 of "ChangeCruiseControlMode".

[0042] If the process has been performed for all the sentences in the requirement specification block ("Yes" in step S407), the antonym information generation process ends.

[0043] Next, the fault tree generation process (step S142) in Fig. 1B will be described in detail with reference to Fig. 5 and Fig. 6. Fig. 5 is a schematic diagram showing the processing contents of the fault tree generation unit 113, and Fig. 6 is a processing flowchart thereof.

[0044] As shown in FIG. 5, the fault tree generation unit 113 uses the requirement specification information 200, the antonym information 500 generated by the antonym information generation unit 112, and the name 510 of the requirement specification block linked to the antonym information to recognize the relationship 520 between the antonym information and generate a fault tree 530.

[0045] In the example of requirement specification information 200 shown in Fig. 2A etc., for the sake of simplicity, there are two requirement specification blocks 210 and 220 and one piece of hierarchical information 230, but in actual requirement specification information, there are usually many more requirement specification blocks and hierarchical information, so it is necessary to generate fault trees for all of them. The flowchart in Fig. 6 takes into consideration the case where there are many such requirement specification blocks and hierarchical information.

[0046] First, in step S601, all hierarchical information indicating the connection relationships between the required specification blocks is obtained from the required specification information 200.

[0047] Next, in step S602, the antonym information stored in the antonym information generating unit 112 and the requirement specification block name associated with the antonym information are acquired. As described in the flow of FIG. 4 and the like, the antonym information generating unit 112 generates antonym information for all requirement specification blocks included in the requirement specification information 200.

[0048] Then, in step S603, one sentence indicating a connection relationship between specific requirement specification blocks is selected from all the hierarchical information acquired in step S601. At this time, which sentence is selected is arbitrary, and for example, the sentences may be selected in the order of description in the requirement specification information 200 or in the reverse order. Note that, if an extension request is described in the connection relationship between the requirement specification blocks, the extension request is also acquired together with the connection relationship.

[0049] In step S604, the name of the required specification block included in the text selected in step S603 is obtained.

[0050] Next, in step S605, the requirement specification block names associated with the opposite information acquired in step S602 are searched for information matching the requirement specification block name acquired in step S604, and the corresponding opposite information is acquired.

[0051] Then, in step S606, the antonym information acquired in step S605 is associated with each connection relationship, and this is saved or output as fault information included in the fault tree. Note that, in order to visualize the fault tree, general spreadsheet software is used in addition to dedicated display software, and therefore the antonym information and the relationship between the antonym information are output in a format suitable for each visualization method.

[0052] In addition, the hierarchical information described in the requirement specification information indicates which requirement specification block is the source or destination of the connection, and this direction is used as a basis to identify which of the defect events is located at a higher hierarchical level.

[0053] Finally, in step S607, it is determined whether processing has been performed for all descriptions of hierarchical information acquired in step S601, and if not ("No"), the process proceeds to step S603 to process the next hierarchical information, and similar processing is repeatedly performed. If processing has been performed for all hierarchical information ("Yes" in step S607), the process ends.

[0054] The above-mentioned fault tree generation process can be modified as necessary. For example, when an extension request is acquired in step S603, more detailed connection relationships between fault events may be described based on the description of the extension request, or the connection relationships (tree structure) themselves may be adjusted.

[0055] For example, in FIG. 7A, in the requirement specification 700, multiple requirement specification blocks (702, 703) are included in the extension requirement for one requirement specification block 701. <derivereqt>However, since these expansion requests are specified in parallel, in the fault events in the fault tree 710, the fault event 711 located at the higher level and the fault events (712, 713) located at the lower levels are connected by an OR gate 714.

[0056] In FIG. 7B, in the requirement specification 720, for one requirement specification block 721, a requirement specification block 722 is an extension requirement " <derivereqt>"Connected with 724, another requirement specification block 723 is an extension requirement" <verify>"Connected on 725. Request extension here" <derivereqt>" indicates additional details of a requirement, so it is reflected in the fault tree as an attachment to the higher-level requirement, whereas " <verify>Since " indicates the relationship between the requirement specifications and the test cases, it is determined that it is not an element of the requirement specifications during product operation and is not reflected in the fault tree. In other words, as shown in the fault tree 730, a block 731 related to a test case failure is not included in the fault tree.

[0057] As described above, according to this embodiment, a fault tree can be generated in the requirements definition process, which is upstream in the design process, and therefore rework during design can be reduced. EXAMPLES

[0058] In this embodiment, the design support device described in the first embodiment is configured to be able to execute a more detailed "Fault Tree Analysis (FTA)".

[0059] Fig. 8A is a block diagram showing the configuration of a design support device 800 in this embodiment. The configuration in this embodiment differs from the design support device 100 in the embodiment 1 shown in Fig. 1A in that a terminal event acquisition unit 814 is added to a main storage device 810, and a terminal event storage unit (terminal event DB) 822 is added to an auxiliary storage device 820, but other elements are similar, so detailed descriptions thereof will be omitted.

[0060] In FTA, the cause of each malfunction is visualized using a fault tree, and the most terminal events that are the source of the malfunction are placed at the bottom level of the fault tree, making it possible to perform a more detailed FTA.

[0061] FIG. 8B shows the overall processing flow in this embodiment, which differs from the processing flow in embodiment 1 shown in FIG. 1B mainly in the addition of step S843 for acquiring a terminal event from the terminal event memory unit 822; however, explanations of overlapping processing in other processing steps will be omitted.

[0062] Next, the terminal event acquisition process in this embodiment will be described in detail with reference to FIGS.

[0063] 9 is an example of information stored in the terminal event storage unit 822 according to this embodiment. Here, the term "component" refers to a part or unit included in the product to be designed, and the term "terminal event" refers to information related to cases of failure or malfunction of these components. Note that, since a case of failure or malfunction of one component may not be uniquely determined, multiple terminal events may be stored for one component.

[0064] Fig. 10 is a diagram showing the process of the terminal event acquisition unit 814 according to this embodiment. As shown in Fig. 10, the terminal event acquisition unit 814 receives the fault tree 1010 output by the fault tree generation unit 813, and adds terminal events to the fault tree by referring to the terminal event storage unit 822. Details of each process will be described below with reference to the flowchart shown in Fig. 11.

[0065] First, in step S1101, the fault tree 1010 output from the fault tree generating unit 813 is obtained.

[0066] Next, in step S1102, a malfunction event 1011 located at the bottom layer is acquired from among the malfunction events included in the fault tree 1010. At this time, the malfunction event located at the bottom layer refers to a malfunction event that is not connected to any malfunction event at a layer lower than the malfunction event in question.

[0067] Next, in step S1103, for the malfunction event 1011 located at the bottom layer, nouns related to part names and the like contained in the malfunction event are extracted. To extract the nouns, a rule-based search method based on regular expressions in the field of natural language processing, morphological analysis, BERT (Bidirectional Encoder Representations from Transformers), and other technologies are used. In this example, the noun "nichrome wire" is extracted.

[0068] Next, in step S1104, the components stored in the terminal event storage unit 822 are searched for the noun extracted in step S1103, and it is determined whether a match exists. In this case, since it is determined that the combination 822A of "component: nichrome wire, terminal event: disconnection" matches, the process proceeds to step S1105, but if a match does not exist ("No" in step S1104), the process proceeds to step S1107. In this case, since the terminal event cannot be added to the fault tree, a message indicating this may be displayed on the output device 803.

[0069] Next, in step S1105, a failure event 1012 to be added to the end of the fault tree is generated using the terminal event found in step S1004. In this example, "disconnection" is defined as a terminal event that can occur due to "nichrome wire defect."

[0070] Next, in step S1106, the generated terminal event is connected to a lower layer of the malfunction event located at the lowest layer acquired in the fault tree, thereby making it a terminal event of the fault tree.

[0071] Finally, in step S1007, it is determined whether processing has been performed for all the defect events located at the bottom layer. If processing has not been performed (if "No"), the process proceeds to step S1002 and repeats the processing, and if processing has been performed (if "Yes"), the process of acquiring terminal events is terminated.

[0072] 12 is an example of a display screen 1200 in the output device 803 according to this embodiment. Here, a generated fault tree 1210 is visualized and displayed, and in addition to the fault tree 1210, input requirement specification information 1220 is also visualized and displayed. Also, a broken line 1230 indicates a correspondence relationship between a malfunction event included in the fault tree 1210 and a requirement specification block in the requirement specification information.

[0073] Furthermore, among the fault events in the fault tree 1210, those generated by the end event acquisition unit 814 may be displayed so as to be distinguishable. Here, as indicated by reference numeral 1211, the frame of the corresponding block is indicated by a dashed line.

[0074] The display screen example 1200 shown in FIG. 12 can be displayed in the same manner in the first embodiment, except for the block 1211 generated by the terminal event acquisition unit.

[0075] As described above, according to this embodiment, when the cause of each malfunction event in FTA is visualized by a fault tree, the terminal event that is the origin of the malfunction is placed at the bottom layer of the fault tree, so that a more detailed FTA can be performed. [Explanation of symbols]

[0076] 100: Design support equipment 101: Central control unit 102: Input device 103: Output device 110: Main memory 111: Input section 112: Antonym information generation unit 113: Fault tree generator 120: Auxiliary storage device 121: Requirement specification information DB< / verify> < / derivereqt> < / verify> < / derivereqt> < / derivereqt> < / derivereqt>

Claims

1. an input unit for inputting requirement specification information including a plurality of requirement specifications for a product or system and information indicating their hierarchical structure; an opposite meaning information generating unit that generates opposite meaning information indicating an opposite meaning to the required specification, thereby generating information indicating a malfunction phenomenon; a fault tree generator that generates a fault tree using information indicating the fault event and information indicating the hierarchical structure; A design support device comprising:

2. The design support device according to claim 1 , The design support device, wherein the opposite information generating unit generates opposite information that indicates negation or impossibility of the required specifications.

3. The design support device according to claim 1 , 2. A design support device, wherein the required specification information is described in Unified Modeling Language (UML).

4. The design support device according to claim 3, The design support device according to claim 1, wherein the fault tree generation unit adjusts a structure of the fault tree based on information of an extension request included in the required specification information.

5. The design support device according to claim 1 , a terminal event storage unit that stores names of components constituting a product or system and corresponding failure cases; an end event acquisition unit that searches whether a noun included in information on a fault located at the end of the generated fault tree is stored in the component name of the end event storage unit, and if so, adds the corresponding fault case to the end of the fault tree as an end event; A design support device comprising:

6. The design support device according to claim 1 , The antonym information generation unit acquires the antonym information by using natural language processing technology to recognize the sentence structure of the description contained in the requirement specification information and generate words that indicate the opposite meaning to the predicate.

7. The design support device according to claim 5, the fault tree generated by the fault tree generation unit and the terminal event acquisition unit; A correspondence relationship between a requirement specification block included in the requirement specification information and the malfunction event included in the generated fault tree; A design support apparatus comprising: a display unit that displays, in the generated fault tree, the terminal events assigned by the terminal event acquisition unit in a distinguished manner.

8. Inputting requirement specification information including a plurality of requirement specifications for a product or system and information indicating their hierarchical structure; By generating opposite meaning information indicating the opposite meaning of the requirement specification, information indicating a defect phenomenon is created; A design support method comprising: generating a fault tree using the information indicating the malfunction phenomenon and the information indicating the hierarchical structure.

Images