Quantitative risk assessment system (QRAS)6223143Abstract A quantitative risk assessment system (QRAS) builds a risk model of a system for which risk of failure is being assessed, then analyzes the risk of the system corresponding to the risk model. The QRAS performs sensitivity analysis of the risk model by altering fundamental components and quantifications built into the risk model, then re-analyzes the risk of the system using the modifications. More particularly, the risk model is built by building a hierarchy, creating a mission timeline, quantifying failure modes, and building/editing event sequence diagrams. Multiplicities, dependencies, and redundancies of the system are included in the risk model. For analysis runs, a fixed baseline is first constructed and stored. This baseline contains the lowest level scenarios, preserved in event tree structure. The analysis runs, at any level of the hierarchy and below, access this baseline for risk quantitative computation as well as ranking of particular risks. A standalone Tool Box capability exists, allowing the user to store application programs within QRAS. Claims What is claimed is: Description ORIGIN OF THE INVENTION
TABLE 1
ESD End State Definition
CAT catastrophic
SEVH severity high
SEVM severity medium
SEVL severity low
MS mission success
PF permanent failure
The permanent failure end state is used with the redundancy feature of the QRAS 12. Next, in step S308, the ESD pivotal events are quantified. Documentation is added in step S310. As described herein above, documentation includes explanations and assumptions provided by an engineer quantifying the failure mode. The documentation is stored in QRAS 12, and includes images as well as text. FIG. 12 is a detailed diagram of an event sequence diagram produced by the build/edit ESD step S304 shown in FIG. 11. The highlighted failure mode 86 (from the hierarchy 62 and which is tagged to the phase/OTI) serves as the initiating event in the event sequence diagram 74. The event sequence diagram 74 includes pivotal events (PE) 74-11 (PE1), 74-12 (PE2), . . . , 74-1n (PEn), and each pivotal event reaches an end state (ES) 74-21 (ES1), 74-22 (ES2), 74-23 (ES3), . . . , 74-2m (ESm). All pivotal events are quantified with the same options as the failure modes, discussed with reference to FIG. 10. Time dependencies are taken from the mission timeline 70. Definitions pertinent to features included in the Event Sequence Diagrams 74 are: Comment Boxes (CB). CBs can appear anywhere in the ESD. They are used for filling in descriptive information regarding the development of an ESD scenario. They have no probabilistic interpretation and are not quantifiable. They do not appear in the event tree which is automatically generated from the ESD. Demand Based Events. These are: (a) Events which occur at the specific time (absolute mission time or time relative to the occurrence of a previous event) an item is called upon (demanded) to function. The outcome of such an event is binary, either success or failure, yes or no, etc. The failure of components to start belong to this class of events; e.g., APU fails to start, SRM fails to ignite. (b) Events which occur over an interval of time, for which the probability of failure over the length of the interval is expressed as a point estimate and an uncertainty distribution. In effect the time interval is considered to be a single demand and the item's performance is classified as either success or failure; e.g., the failure probability of an SSME over the Space Shuttle's ascent phase of 520 seconds may be expressed as a point value with an uncertainty distribution-in this sense, the success or failure of the SSME in that interval is a demand based event. End State (ES). An ES is the last event in an ESD scenario, and is a termination point of an ESD scenario. Each scenario in an ESD terminates in a single ES. An ESD can have many scenarios. Allowable ESs are: (a) Catastrophic (CAT) (b) Mission Success (MS) (c) Mission Success (MSR) (but with failure of a redundant subsystem) (d) Loss of Mission (LOM) (but, not catastrophic) Permanent Failure (PF) (of a subsystem) (this end state is to allow the off-line use of QRAS ESDs for calculating intermediate results--usually of redundant subsystems--that is subsequently used in other on-line QRAS ESDs that lead to one or more of the end states in (a) through (d), above). Severity High, Medium, or Low (SEVH, SEVM, SEVL, respectively): These allow the user to define other degradation categories that may be useful to track. Event Sequence Diagram (ESD). An ESD depicts one or more accident or failure scenarios, all of which begin with a single initiating event, may include one or more pivotal events and/or time conditions, and terminate in one or more specified end states. Initiating Event (IE). This is the first event in an ESD. An IE is an abnormality, malfunction, or failure (human, hardware, software, process, or other) that causes a deviation from desired operation. IEs are synonymous with failure modes in the QRAS system hierarchy in a specific operational time interval. Each ESD begins with a single IE. An IE can be a time distributed event during a particular time interval (the time-to-event distribution, or a point estimate and uncertainty for the event probability over the time interval, and the start and end times (absolute time) for the interval must be specified) or it can be a demand based event occurring at a specific point in time (the point estimate and uncertainty of the event probability). Operational Time Interval (OTI). A time interval which is subordinate to a phase and unique to a specific subsystem. The runtime of a subsystem in a particular phase may be divided into multiple OTIs. Phase. One of a number of time intervals unique to the top-level system under analysis; e.g., for the Space Shuttle: pre-ascent, ascent, on-orbit, and re entry/landing are four phases. Pivotal Event (PE). An event in an ESD scenario after the initiating event and before the end state(s). Pivotal events (PEs) determine whether and how an IE propagates to a specified end state. PEs may be protective, mitigative, aggravative, or benign events which help determine whether and how an IE propagates to a specified end state. Multiple PEs may be used to reach an end state. It is also permissible to have no PEs in those cases where an IE propagates directly to a single end state. A PE name should be phrased as a question that can be answered "Yes" or "No" and should be entered into the upper part of the PE box. Designators of PEs are defined automatically by QRAS and entered into the lower part of the PE box. The two outlinks are annotated "Yes" or "No." Each outlink is represented by a line emanating from the PE. "Yes" lines are horizontal and come from the right side of a PE. "No" lines are vertical and come from the bottom of a PE. The PE "Yes" outlink is assigned a time distributed or demand based probability of occurrence and an uncertainty in accordance with the specifications for characterizing a failure probability. The probability of the "No" outlink is automatically be computed by the QRAS system. Time Distributed Events. In contrast to "demand based events" (see earlier definition), these are events with specified time-to-occurrence distributions within a given time interval. The failure of components while in operation belongs to this class of events; e.g., APU fails to run after it has run for a time, t, given that it has started to run. Time Condition (TC). A time condition determines the path that is followed through an ESD scenario beyond the TC point, depending on an absolute or relative time constraint. TCs are based on deterministic time limits and the allowable choices are:
a. t .gtoreq. a d. t < b g. a .ltoreq. t < b
b. t > a e. a .ltoreq. t .ltoreq. b h. a < t .ltoreq. b
c. t .ltoreq. b f. a < t < b
where t is the time variable over the time interval of the ESD and a and b are values of absolute or relative time; e.g., mission elapsed time or time relative to (after) another specified event (the time units are assumed to be the same as the default units of the "phase" in which the ESD applies). For the Space Shuttle, default time units for its phases are: pre-ascent in seconds, ascent in seconds measured from T-0 (with SSME start at T-6), on-orbit in days measured from end of ascent, and entry in minutes measured to wheel stop. The two outlinks are annotated "Yes" or "No." Each outlink is represented by a line emanating from the time switch. "Yes" lines are horizontal and come from the right side of a time switch. "No" lines are vertical and come from the bottom. TCs that are satisfied are effectively transparent to the scenarios in which they reside. TCs that are not satisfied divert their scenarios onto alternate paths. TCs appear in the event tree automatically generated from the ESD by the QRAS system. TCs work in conjunction with IEs or PEs. A TC may be placed in a scenario after a time dependent PE and attached to either of its outlinks, whichever is appropriate. A TC may also be used in an ESD which begins with a time dependent IE. FIGS. 13, 14A, 14B, and 15A-D are flowcharts of the functions provided by the Include: Multiplicities, Dependencies, Redundancies module 54 shown in FIG. 4. The Include: Multiplicities, Dependencies, Redundancies module 54 corresponds to, and implements the functions provided in, the Include: Multiplicities, Dependencies, Redundancies step S18 shown in FIG. 3. FIG. 13 is a flowchart 90 of an overview of the Include module 54. As shown in step S400 of FIG. 13, the user highlights an element 64, a subsystem 66, or a failure mode 68 in the hierarchy 62, using the Include module 54. Next, in step S402, the user selects using the Include module 54, the inclusion of either multiplicities, redundancies, or dependencies. Multiplicities place within the hierarchy 62 a multiplicity number k next to the selected element, subsystem, or failure mode. The multiplicity number k indicates that the selected element, subsystem, or failure mode is accounted for k times in analyzing the risk of system 63 by the QRAS 12. For example, and referring now to FIG. 5A, the hierarchy 62 indicates therein with a multiplicity number (3) that there are 3 SSMEs within the Space Shuttle 63. Therefore, instead of having to build 3 identical elements, one for each SSME, the user indicates with the multiplicity number (3) that 3 SSMEs must be accounted for by the QRAS 12 in analyzing the risk for the Space Shuttle 63. Likewise, and also shown in FIG. 5A, multiplicity number (122) indicates that there are 122 failure modes for the porosity in the subsystem 66-1. Also as shown in step S402, the user may select redundancies using the Include module 54. Redundancies enter into the hierarchy a factor of k-of-N, meaning that the system 63 needs k of N elements 64, subsystems 66, or failure modes 68 to work to avoid catastrophic failure. In addition, and also as shown in step S402, the user may select dependencies using the Include module 54. The selection of Dependencies causes the Include module 54 to display a screen allowing the user to enter the .beta. for the selected element, subsystem, or failure mode. The .beta. is the factor for common cause failures. Also from the Dependencies selection, or from the hierarchy 62, the Include module 54 creates a fault tree for cross subsystem 66 or element 64 dependencies, as shown in step S500 in FIG. 14A. An example of a fault tree 92 is shown in FIG. 14B. As shown in FIG. 14B, fault tree 92 accounts for situations in which and/or logic regarding multiple elements or subsystems is included in assessing by QRAS 12 the risk associated with system 63. In the fault tree 92 example shown in FIG. 14B, failure modes 94, 96, 100, and 102 contribute to the risk for system 63 based upon logic associated with OR gates 98 and 104, an AND gate 106. FIGS. 15A-D are flowcharts of the functions provided by the Include: Multiplicities, Dependencies, Redundancies module 54 shown in FIG. 4. The Include: Multiplicities, Dependencies, Redundancies module 54 corresponds to, and implements the functions provided in, the Include: Multiplicities, Dependencies, Redundancies step S18 shown in FIG. 3. Multiplicities are included in the QRAS 12 as shown in flowchart 108 in FIG. 15A. In step S600, the Include module 54 highlights an element 64, subsystem 66 or failure mode 68 based upon user input. Then in step S602, a multiplicity number k is chosen by the user and input into the Include module 54. Then, the hierarchy 62 is modified by the symbol k. For example, by using the Include module 54, if the user highlights a subsystem 66-1 (step S600) and inputs k=3 as the multiplicity number (step S602), then the hierarchy 62 is modified by Include module 54 to repeat subsystem 66-1 3 times within the hierarchy 62 or (preferably) to maintain only one representation within the hierarchy 62 of subsystem 66-1 but indicate within the hierarchy 62 that subsystem 66-1 should be processed as repeated 3 times (step S604). Redundancies are included in the QRAS 12 as shown in flowchart 110 in FIG. 15B. In step S800, the Include module 54 highlights an element 64 or subsystem 66 based upon user input. Then in step S802, the Include module 54 allows the user to input a k-out-of-N number for success, and stores the number input by the user. The hierarchy 62 is modified by the Include module 54 by the symbol (K-of-N), in step S804. Dependencies are included in the QRAS 12 as shown in flowchart 112 in FIG. 15C. In step S900, the Include module 54 highlights an element 64 or subsystem 66 based upon user input. Then in step S902, the Include module 54 completes, based also on user input, common cause .beta. values for catastrophic failure (CAT) and permanent failure (PF). Dependencies across elements 64 and subsystems 66 are included in the QRAS 12 as shown in flowchart 114 in FIG. 15D. In step S1000, the hierarchy feature (i.e., an element 64 or subsystem 66) about which the fault tree 92 is to be established is selected by the Include module 54 based upon user input. Then in step S1002, the Include module 54 builds the fault tree 92 by allowing the user to highlight elements 64 and/or subsystems 66 and to "click" with the mouse on Fault Tree Symbols (i.e., AND-OR logic symbols). Once steps S10-S18 shown in FIG. 3 have been completed by, respectively, modules 46-54 shown in FIG. 4, a risk model for system 63 has been constructed by QRAS 12. Once the risk model is constructed, the QRAS 12 includes a lock feature (with password) to prevent unauthorized users from changing data provided in the risk model. In addition, Copy/Paste features exist for the hierarchy 62. Further, quantification features provided in the quantify failure modes/documentation module 50 are linked to Mathematica. The Create Fixed Baseline 56 and Generate Analysis Runs 58 modules correspond to, and implement the functions provided in, the Create Baseline and Generate Analysis step S20 shown in FIG. 3. The Create Fixed Baseline 56 and Generate Analysis Runs 58 modules shown in FIG. 4 provide 4 main options: (1) create a baseline simulation; (2) delete baseline; (3) view a prior stored analysis; and (4) create a new analysis. The delete baseline option (2), when selected by the user, simply removes the current baseline from QRAS 12. The view a prior stored analysis option (3), when selected by the user, simply retrieves from memory a prior stored analysis, and displays the analysis to the user. The create a baseline simulation option (1) and the create a new analysis option (4) are explained in further detail, with reference to FIG. 16. FIG. 16 is a flowchart of the create a baseline simulation option (1) and the create a new analysis option (4) functions provided by the Create Fixed Baseline 56 and Generate Analysis Runs 58 modules shown in FIG. 4. Selection of the create a baseline simulation (option (1)) results in the flowchart 116 shown in FIG. 16 being executed, beginning with step S1100 and continuing through step S1112. In step S1100 shown in FIG. 16, simulation parameters are first set, based on user input. Then, in step S1102, the baseline simulation is created. Creating a baseline simulation includes resolving all event sequence diagrams 74 and executing simulations created and stored at the level of the phase/OTI/Scenario. The baseline is created based upon simulations run at the lowest level possible, i.e., the failure mode level 68. The simulations are saved and stored as the baseline. The baseline is then password-protected, so that the same analysis results for each execution of QRAS for each system 63. Only a user having the password is able to change the baseline. Selection of the create a new analysis (option (4)) also results in the flowchart 116 shown in FIG. 16 being executed. Execution of flowchart 116 begins with step S1104. In step S1104, the level (system 63, element 64, subsystem 66, or failure mode 68) of the hierarchy 62 is then selected by being highlighted based upon user input. An analysis run is created in step S1106 for the selected level and the levels below the selected level. For example, if an element 64 is highlighted, then an analysis run is created for the element 64, the subsystems 66 belonging to that element 64, and the failure modes 68 belonging to each subsystem 66 belonging to the element 64. Risks are then ranked by subsystems, failure modes, and scenarios, in step S1108. Options for ranking of risks provided by QRAS 12 include mean, median, or uncertainty. A more detailed discussion of ranking of risks by QRAS 12 is provided with reference to FIG. 17. Point estimates and uncertainty distributions are run at the selected (highlighted) level, in step S1110. QRAS 12 provides point estimates or complete uncertainty. In step S1112, an event tree 76 is created by QRAS 12 if a failure mode 68 is selected by being highlighted. The Create Fixed Baseline 56/Generate Analysis Runs 58 modules provide analysis runs for a single phase or for multiple phases. Further, the analysis can be deleted, or saved with documentation. Also, an end state can be selected based upon user input, and the baseline can be deleted and reestablished. FIG. 17 shows options 118 for selecting risk ranking provided by the Create Fixed Baseline 56 and Generate Analysis Runs 58 modules. As shown in FIG. 17, risk is ranked by scenario, by failure mode/initiating event, by elements/subsystems, or by single point failures. For all of the above-mentioned ranking options, further options to rank by mean, median, or uncertainty are also provided. If the option of ranking by elements/subsystems is selected, then for clusters, several display options are provided such as displaying both clusters and singletons, displaying only the singleton representation of a cluster, and displaying only the cluster and excluding the singleton representative of the cluster. If the option of ranking by a single point failure is selected, then only singleton scenarios apply. FIG. 18 is a flowchart 120 of the functions provided by the Perform Sensitivity Analysis module 60 shown in FIG. 4. The Perform Sensitivity Analysis module 60 corresponds to, and implements the functions provided in, the Perform Sensitivity Analysis step S20 shown in FIG. 3. The main functions provided by the Perform Sensitivity Analysis module 60 include the options of (1) creating a new analysis, (2) modifying an existing analysis, (3) deleting an existing analysis, and (4) viewing a prior analysis. For option (3), delete existing analysis, the sensitivity analysis module 60 simple deletes an existing analysis selected by the user. For option (4), viewing a prior analysis, the sensitivity analysis module 60 simply displays to the user a prior analysis retrieved from memory. When the user selects either option (1), creating a new analysis, or (2), modifying an existing analysis, flowchart 120 shown in FIG. 18 is executed. As shown in step S1200, a hierarchy level is highlighted based upon user input. The hierarchy level determines the range of hierarchy for sensitivity runs. All parts of the range hierarchy have an (S) appended thereto. Then, for modification of an existing analysis (option (2)), an existing analysis is selected at the highlighted hierarchy level or above, in step S1202. An existing analysis can be selected for modification multiple times, then run. When option (1), creating a new analysis, is selected, step S1204 is executed. In step S1204, selection from the following options provided by the sensitivity analysis module 60 is available: 1 Modify Failure Mode 2 Remove Subsystem 3 Remove Fail Mode 4 Add Fail Mode 5 Modify ESD 6 Replace subsystem with subsystem from-another Project 7 Change Redundancy/Multiplicity. After a new analysis has been run in step S1204, analysis results as in steps S1108, S1110, and S1112 in flowchart 116 of FIG. 16 are provided, but with the original analysis and the sensitivity results presented side-by-side, in step S1206. Other features provided by the sensitivity analysis module 60 include saving modified settings, but not running an analysis, and viewing documentation provided and stored in QRAS 12. FIG. 19 shows a selection 122 of stand-alone programs 122 accessed from the main screen of QRAS 12 and residing in the toolbox 16 shown in FIG. 5A. QRAS 12 provides a seamless interface to each of the programs 122, initiating execution of the selected program, providing required input, and displaying results to the user. As shown in FIG. 19, the QRAS toolbox 16 provides access to the following programs 122: 1. Bayesian Update Program 2. Expert Opinion 3. Mathematica The Bayesian Update Program (1), Expert Opinion (2), and Mathematica (3) are fixed programs provided with QRAS 12. MATHEMATICA and the BAYESIAN UPDATE PROGRAM are known. Expert Opinion includes various techniques of analyzing risk posed by experts in the field. Additional programs, such as a Monte-Carlo Simulation Program to handle hyper-distributions, for example, can be added to QRAS 12 by the individual users. The toolbox 16 allows users to add programs of their choice. FIGS. 20A, 20B, and 20C show utilities provided by QRAS 12 distributed across QRAS 12 and available to users from a variety of the modules 46-60 of QRAS shown in FIG. 4. The utilities shown in FIGS. 20A, 20B, and 20C are available from pull-down menus provided in QRAS 12. FIG. 20A shows edit functions copy and paste, applicable principally to the build hierarchy module 46 and provided therein. The edit utilities include coping part of the hierarchy 62 within itself, copying part of hierarchy 62 from one project 63 to another project 63, or copying as previously described but including not only the structure of the hierarchy 12 but all quantifications 50 and events sequence diagrams 74. FIG. 20B shows options provided by the model report utility 126 of QRAS 12. In the model report utility 126, all or part of the model for a project (such as the hierarchy 62, the event sequence diagrams 74, the event trees 76, etc) can be printed on a printer. In addition, analysis results 59 (as shown FIG. 5A) can be exported from the QRAS 12 system installed on the current computer to a QRAS system 12 stored on another computer. Alternatively, just the structure of the hierarchy 62 can be printed, or all quantifications 50 and event sequence diagrams 74 can be printed (or exported). FIG. 20C shows a lock project utility 128 provided within QRAS 12. The lock project utility 128 is applicable to the build hierarchy module 46, the create mission time line module 48, the quantified failure modes/documentation module 50, the build and quantify ESDs module 52, the include: multiplicities, dependencies, and redundancies module 54, and the create fixed base line module 56 of QRAS 12 after creating the base, the users supplies passwords which are required to alter any of the data inserted into the above-mentioned modules 46-56. Using the lock project utility 128, the base line and all quantifications can be viewed, but not changed unless a password is supplied. The lock project, therefore, preserves the model that is used for risk analysis. EXAMPLE OF QRAS 12 The following section shows one example of QRAS 12 of the present invention, including WINDOWS-based screens and explanations of QRAS 12 functions provided by features selected from the screens. The following example shows how to create a system model and create and run an analysis using QRAS 12, and discusses the toolbox features and special features of QRAS 12, after a brief explanation of installing the example of QRAS 12. QRAS 12 is installed by double clicking the QRAS.exe program. QRAS 12 requires conventional MATHEMATICA (Professional version). Once MATHEMATICA is installed on the computer, QRAS 12 must be linked to MATHEMATICA: (a) In the MATHEMATICA directory is found two folders: Autoload and Addons. First, click on Addons and copy the Statistics sub-folder (located under Standard Packages) into the Autoload folder; (b) QRAS 12 expects MATHEMATICA to be in its standard place: C:.backslash.Program Files.backslash.Wolfram Research.backslash.Mathematica.backslash.3.0. If this is the case, then nothing needs to be done; however, if MATHEMATICA is installed elsewhere, the QRAS 12 file that links to MATHEMATICA must be modified. More particularly, in the file Qras.ini in the Windows directory on the C drive, the line beginning with: InitString=must be changed to read: InitString=-linkname `location of Mathematica.backslash.mathkernel`-mathlink. MATHEMATICA must be personalized by entering the password provided. To do this, click on mathematica.exe and enter the password in the designated field on the screen. 1. Creating a system model Creating a system model begins with creating/opening/locking a project. All information about a specific system model resides in a single Windows 95 folder. This set of information is referred to as a "project." 63, discussed herein above. For example, a model of the Shuttle is a "project"; a model of a new turbopump could be a "project." When the user first runs QRAS 12, the main screen 130 appears. The main screen 130 is shown in FIG. 21 and includes two active buttons: (a) Create New Project 132; and (b) Open Existing Project 134. Clicking "Create New Project" 132 creates a dialog box, requesting a project name. This name is automatically used to create and name a new folder under the "Projects" folder. The new folder holds all information about the project 63, corresponding to the root or project shown in FIG. 5A. Clicking "Open Existing Project" 134 displays a list of current projects. Also shown as options on the main screen 130 are the Build Risk Model function 136, corresponding to the Build Risk Model step S08 shown in FIG. 3 and the Build Risk Model Module 45 shown in FIG. 4. The Build Risk Model function 136 includes 4 active buttons: the System Hierarchy Manager 138, corresponding to the Build Hierarchy step S10 shown in FIG. 3 and to the Build Hierarchy module 46 shown in FIG. 4; the Mission Timeline function 140, corresponding to the Create Mission Timeline step S12 shown in FIG. 3 and to the Create Mission Timeline module shown in FIG. 4; the Failure Mode Quantification function 142, corresponding to the Quantify Failure Modes step S14 shown in FIG. 3 and to the Quantify Failure Modes/Documentation module 50 shown in FIG. 4; the ESD function 144, corresponding to the Build/Edit ESD step S16 shown in FIG. 3 and to the Build and Quantify ESDs module 52 shown in FIG. 4; and the Multiplicity/Redundancy function 146, corresponding to the Include: Multiplicities, Dependencies, and Redundancies step S18 shown in FIG. 3 and to the Include: Multiplicities, Dependencies, and Redundancies module 54 shown in FIG. 4. The Run Risk Model function 148 shown in FIG. 21 includes 2 active buttons: the Create New Analysis function 150, corresponding to the Create Baseline and Generate Analysis step S20 shown in FIG. 3 and to the Create Fixed Baseline module 56 and the Generate Analysis Runs module 58 shown in FIG. 4; and the View Analysis Results function 152, which displays the results of the analysis generated by the Create New Analysis function 150 or by a previously-generated, and stored, analysis 59 shown in FIG. 5A. The Perform Sensitivity Analysis function 154 includes the Sensitivity Analysis function active button 156, corresponding to the Perform Sensitivity Analysis step S22 shown in FIG. 3 and to the Perform Sensitivity Analysis module 60 shown in FIG. 4. Main Screen 130 includes the Tool Box function 158. The Tool Box 158 corresponds to the Tool Box 16 shown in FIG. 5A. In the example shown in FIG. 21, the Tool Box 158 includes 3 active buttons, the selection of any of which invokes either conventional programs provided by the user or other conventional programs such as MATHEMATICA 160, Bayesian Updating 162, and Fault Tree 164. 2. Using the hierarchy manager The user double clicks the desired project 63 and the hierarchy screen 166 shown in FIG. 22 is automatically generated. At the top of the hierarchy screen 166 appear menu options 167 for the user to go directly to the functions 138-158 described with reference to FIG. 21, to a different project 63, or to file 168 or edit 170 options. The file option 168 can be used to open or close a project. The user can invoke any of the functions 138-158 shown on the main screen 130 either from the main screen 130 or from the hierarchy screen 166 (or from other screens as described). Referring now to FIG. 22, the hierarchy screen 166 shows an element/subsystem/failure mode hierarchy 62, including a project 63, elements 64 and 64-1 of the project, subsystems 66-1 and 66-2 of the elements, and failure modes 68 corresponding, respectively to the elements 66-1 and 66-2. The hierarchy screen 166 indicates that the element/subsystem/failure mode hierarchy 62 is unlocked 172. The hierarchy 62 appears in every window, and the user highlights the part of the hierarchy 62 in which the user is interested, and this highlighted part of the hierarchy serves as the link to other modules or features. When the hierarchy is complete, all failure modes have been quantified, and all ESDs input, the project can be "Locked" to prevent modification of the input data. Under the "File" Option 168, a feature is available called "Lock Project." The user supplies a password and locks a given project; the user can also "unlock" the project and change passwords. These options appear under "File" 168 at the top of the screen. The Hierarchy Manager is used to construct a decomposition of the system: root level, elements, subsystems, (sub-subsystems if desired) and failure modes-in descending order. To begin, first click "Hierarchy" at the top of the screen 166 and select the "Build/Edit Hierarchy" option 138 in the pull-down menu. This will activate all options for the Hierarchy Manager. Again click "Hierarchy" and select the options to build the hierarchical decomposition. The options are, in almost every case, self explanatory. There are tool bar items for some of the options. These include "Add Element," "Add Subsystem," "Add Failure Mode," and "Rename." The "Rename" button allows changing the standard names such as "Element" or "Failure Mode" to specific names such as "SSME" or "Weld Failure." (One can also highlight the component (e.g., subsystem, failure mode) to rename and push the F2 key. This will automatically bring up the rename dialog). There are also "Move Up" and "Move Down" options. These allow interchanging positions of the highlighted element/subsystem/failure mode with the one below (or above) it. In addition to creating the actual hierarchy, there are options for adding documentation (called "Documentation") and storing pictures (called "Images"). A "Documentation" button applies to subsystems and elements--not failure modes. Failure mode documentation is handled in the "Failure Mode Quantification" screens and in the "Event Sequence Diagram" screens, explained herein below. An element cannot be nested under another element; however, a subsystem can be nested under another subsystem (in effect, to create a sub-subsystem). The OTIs (refer to the Mission Time Line discussion below) apply to the lowest level subsystem. The Hierarchy is automatically saved as one builds it. Thus the "Save" button is not needed for the Hierarchy; all other features (e.g., the Event Sequence Diagram) must be saved by the user. 3. Creating the Mission Time Line The mission time line (element 70 shown in FIG. 5A) does two things: creates global "phases" (for the system) and creates "operational time intervals" (for subsystems). "Phases" for a project are at the top system level, referred to as the "Root" 63 in the hierarchy 62. These phases represent global system demarcations, and most analyses are run by phase. For the Shuttle, the phases are "Ascent," "On-orbit," and "Reentry." The user defines up to 10 phases. At least 1 phase must be created. "Operational time intervals (OTIs)" are created for each subsystem (within an element), within a given phase. The OTIs establish the start and end times for distinct operating modes of a subsystem. Each subsystem must have at least 1 OTI. OTIs allow multiple quantifications and/or ESDs for a single failure mode within a phase. Therefore, OTIs apply to a subsystem, and each failure mode and ESD is tagged to a set of specific OTIs for that subsystem. To create a mission time line, first click "Mission Time Line." 140 Next click the "Define Mission Phases" option. The Mission Phase Editor 174 shown in FIG. 23 is then displayed. The subsequent buttons and operations for creating phases are self-explanatory, including the phase information 178, the phase name 180, the start time 182 for the phase, the end time 184 for the phase, the units 186 for the start time 182 and the end time 184, updating 188, adding a phase 190, deleting a phase 192, print 194, save 196, and cancel 198. The Mission Phase editor screen 174 allows the user to establish the global system operations phases, including the start and end times for each phase. To create OTIs, first highlight a subsystem 66-1 in the hierarchy 62 on the Operational Time Interval screen 176 shown in FIG. 24. Then click the "Create Operational Time Intervals" option 200 in the mission time line menu 140. Highlight the phase for the OTI and use the "Add OTI" button 202. All start and stop times must fall within a phase. Allowable times are displayed in green; erroneous or questionable times are displayed in red. In the example shown in FIG. 24, the High Pressure Fuel Turbopump (HPFTP) 66-1 has been highlighted, so the OTIs created will correspond to the HPFTP subsystem 66-1. Finally, the failure modes in the system hierarchy must be tagged to the OTIs. To do this, highlight a failure mode 68 and then, in the mission time line menu 140, click "Make OTI Applicable." (not shown). A grid (not shown) will appear below the hierarchy 62, with a box called "APP"--for "applicable." (not shown). An "X" will appear within the box. As discussed herein above, the mission phase times and OTI times may run from -x to +y. That is, the user can code minus times, if desired. In the Shuttle, for example, the ascent phase runs from -5 minutes to +13 minutes. 4. Quantifying Failure Modes The Quantification Model Selection screen 204 is shown in FIG. 25 and is the top level screen for Failure Mode Quantification. "Housing Structural Failure" has been highlighted in the hierarchy 62 (in the example shown in FIG. 25) and the limit state function 206 has been selected as a method of quantification in the example shown in FIG. 25. Generally, in QRAS 12, to quantify a failure mode, first highlight the desired failure mode 68. Next, highlight an OTI in a grid below the hierarchy 62 (or in a dialog box to the left of the hierarchy). Finally, click on the top level menu option entitled "Failure Mode Quantification." The drop down menu that then appears has only one option: "Quantify Failure Mode." Clicking this option will bring up the main failure mode quantification screen. There are now 2 main options for quantification: demand based, or time based. Demand based. The demand based feature has 2 options: Instantaneous events (the user can enter a specific time t.sub.0 ; or indicate the event is instantaneous but the time is not specified; e.g., fails to start, but start time not specified); or "Success/Failure-viewed over a time interval." This latter option allows quantification where a fixed time interval of operation is considered and the user wants to quantify whether failure has occurred at any time over the interval. In effect, the time interval is considered a single demand. For example, in the Space Shuttle, the high pressure oxidizer turbopumps run for approximately 520 seconds during ascent. One may want to quantify a failure mode of the turbopump by considering the probability of failure during ascent; i.e., a success/failure demand based, rather than strictly time based, quantification. FIG. 26 shows the Demand Based/Point Estimate and Uncertainty screen 208, which includes a Documentation button 210 for entering documentation. The lognormal distribution for P has been selected, and a graph of the uncertainty on P is displayed. Prior to quantification, a failure mode 68 in the hierarchy 62 has been highlighted. In addition, a probability density function (PDF) and a cumulative density function (CDF) can be selected on screen 208. Time based. The time based option is self-explanatory. A detailed description of the failure mode quantification options is provided herein below. A failure mode must be quantified for each OTI for which it has been made "applicable." In every quantification option, there is an input screen which contains a "Evaluate" button. "Evaluate" means: verify the legitimacy of the supplied input parameters and create the uncertainty distribution. The evaluate button must be clicked to complete a quantification. When quantifying a failure mode, an uncertainty distribution on the probability of failure is input. The pull-down menus on various screens provide for allowable parameter combinations to determine the distribution. Once "Evaluate" is clicked, the software will determine if any part of the distribution lies outside the interval [0,1]. A message will appear indicating how much of the distribution will be truncated to fit in [0,1], and what the mean of the new distribution will be, based on this truncation. The options for "limit state function" and "p as a function of variables" require the user to input a mathematical function. This function must be entered in Mathematica.RTM. notation. 5. Creating Event Sequence Diagrams Event Sequence Diagrams (ESDs) represent the possible propagation of events, given the occurrence of an initiating event. For QRAS 12, "initiating events (IEs)" are synonymous with "failure modes." So, for each failure mode/OTI combination, an ESD 74 is constructed that shows the potential propagation of the initiating event to various "end states." The ESD screen allows the user to construct ESDs, quantify pivotal events, label end states, and store documentation. An event tree 76 for each ESD 74 is automatically constructed and quantified when the Analysis screen is run. Also note, by definition, a complete path in an event tree is called a "scenario." To construct an ESD, first highlight a failure mode 68 (in the hierarchy 62). Next, highlight the applicable OTI in the grid (not shown) below the hierarchy. Then, click on the "Event Sequence Diagram" option at the top of the screen. Finally, click on "Build/Edit Event Sequence Diagram" in the pull-down menu (not shown). A green circle (the IE or synonymously, Failure Mode 68) appears, connected to a dotted box--the "place holder." (not shown). There is a floating tool bar 212 on the upper left portion of the Event Sequence Diagram screen 214, shown in FIG. 27. This tool bar 212 contains buttons: an arrow, a pivotal event (square box), a comment (parallelogram), and an end state (diamond). Depressing the arrow will deactivate the other buttons. One builds the ESD 74 by placing the cursor on a place holder 74-n and clicking. Whatever tool bar 212 symbol button has been depressed will then be placed in the ESD 74-n in lieu of the placeholder. The entire ESD 74 is constructed in this manner. In the example shown in FIG. 27, the Housing Structural Failure 68 is highlighted, and an event sequence diagram 74 is constructed for the Housing Structural Failure 68. The OTI grid 216 is checked by QRAS 12 to construct the ESD 74. The ESD 74 shown in FIG. 27 applies to the Housing Structural Failure 68 for the "Ascent/OTI 1" Phase combination. There are additional features for inserting, copying, and deleting that appear in the Event Sequence Diagram pull-down menu 144, but which are not shown in FIG. 27. To quantify and document the ESD pivotal events and to label end states, the pull down menu 144 can be used. Alternatively, click on an ESD element 74-n, and right click. If "select a place holder" message (not shown) appears, it means that the "arrow" in the floating tool bar 212 is not depressed; simply toggle it off. All options pertaining to that symbol will then appear in a pull-down menu. A "PE Time Duration" option (not shown) is used when quantifying pivotal events with an exponential or Weibull distribution. The option allows the user to change the time duration for the pivotal event. The default is zero, so that the user must supply a time length; if none is supplied, a warning message will be given. When using a "Copy" (not shown) option, only the structure of the ESD segment will be copied. The quantifications and names will not be copied. An "Insert" (not shown) feature will insert an ESD symbol 74-n after the symbol that is clicked on. The user can quantify the failure mode (or, equivalently, "initiating event") in the ESD; however, the quantification and documentation are preferably entered via the "Failure Mode Quantification" option 142 in the top-of-screen menu options 167. 6. Creating/Running an Analysis Creating/Running an Analysis includes running a standard analysis and running a sensitivity analysis. 6a. Running a Standard Analysis All standard analyses are run from the "Analysis" 150 top-of-screen menu option 167. Note that the pull-down menu for "Analysis" 150 contains 4 options: Create Baseline; Create/Run Analysis; View Prior Analysis Results; and Delete Baseline. Each of these 4 options is explained below. 6.a.1. Create Baseline. Assume that the hierarchy 62 is newly-established, the mission time line 70 has been newly-created, the failure modes 68 have been newly-quantified 50, and the ESDs 74 have been newly-created. The Baseline of QRAS 12 avoids continually generating scenario simulations, thus avoiding re-constructing and re-simulating all scenarios for each analysis run. Specifically, after all the data are input, the user runs a "Create Baseline" function of QRAS 12, which invokes the Create Fixed Baseline module 56 shown in FIG. 4. The Baseline is then constructed: this consists of the lowest level scenarios, with uncertainties simulated, at the OTI level. Then, when analysis runs are made, the Baseline model is used to "sum-up" the lowest level scenarios to produce the desired analysis. The user can construct the Baseline in stages. A Baseline will be constructed for whatever level is highlighted in the hierarchy 62 (and, by definition, all lower levels). If other portions of the hierarchy 62 are then highlighted, that portion of the Baseline is constructed and appended to the other Baseline parts already constructed. Similarly, the user can delete portions of the Baseline--for example, if a quantification error was found--and rerun those parts. Finally, the Baseline can be constructed for only point estimates or point estimates with uncertainty. The point-estimate-only version (which computes the "rare event" approximation) is useful when initially looking over the data; the full uncertainty version is needed to do a complete analysis. Two parameters that apply when generating the uncertainty option are the probability truncation limit and the Monte Carlo sample size. The defaults (10.sup.-20 and 10,000 trials, respectively) can be changed in the qras.ini file included with QRAS 12. Once the baseline is established, the baseline-creator can "lock" both the baseline and associated hierarchy/failure modes data/ESD data. This prevents other users from changing the basic data (e.g., a failure mode quantification). To "lock" the baseline and associated data, click on "File" 168 at the top of the screen 167, and then click on the "Lock" option (not shown). The user is then prompted for a password by QRAS 12. To later delete the baseline or modify the hierarchy (or failure mode/ESD data) this password must be supplied. 6.a.2. Create/Run Analysis. First the user highlights the highest level in the hierarchy 62 for which analyses are desired; e.g., highlight a failure mode 68, subsystem 66, element 64, or the root 63. Next the user clicks on "Create/Run Analysis." (not shown), in which the user enters a name for the analysis (the analysis will be saved and can be recalled later under that name) and highlights a phase or contiguous phases for analysis; or selects a "time slice" option (not shown), to create an analysis that contains any portion of the entire mission time line. The user then supplies any textual documentation desired and clicks the "Run" button (not shown). The Results screen 218 shown in FIG. 28 is automatically displayed. The Results screen 218 contains 3 tabs: Quantitative Results Total 220; Quantitative Results Ranking 222; and Event Trees 224. The Total tab 220 provides the mean estimate of risk and uncertainties. One can highlight a higher or lower level in the hierarchy 62 (provided the analysis encompassed this level) and see the results for that level. (That is, when one runs an analysis at a given level, all analyses at lower levels are also computed). The Ranking tab 2222 provides a ranked list of scenarios (ranked by total mean contribution to risk--at the level highlighted in the hierarchy 62); or ranked by failure mode/initiating event. Risks can also be ranked by the median and by importance measures. One can also examine a scenario in detail by highlighting that scenario and clicking the "View Complete Scenario" button (not shown). To see an individual event tree, note first that each event tree is tagged to a failure mode--OTI combination. So first a failure mode is highlighted and an OTI (in the grid below the hierarchy) is highlighted. Then the Event Trees tab 224 is clicked. In the example shown in FIG. 28, the portion for the quantitative totals and uncertainty has been selected. The level selected is the HPFTP, so that the results are for this subsystem 66-1. Highlighting another part of the hierarchy 62 will automatically display the results for that level. The view prior analysis results and the delete baseline options are self-explanatory based on the remarks above. 6.b. Running a Sensitivity Analysis A sensitivity analysis, or "what if" analysis, allows the user to change quantifications of failure modes and/or event tree pivotal events, remove failure modes or subsystems; and add failure modes or entire subsystems. These changes are not permanently stored. To create a sensitivity analysis, first the user highlights a level in the hierarchy 62. This level constitutes the "domain" of the sensitivity analysis; and all sensitivity analyses (for the given run) must be at or below this level. Also, a standard analysis must have been previously run covering this level. The requirement for an existing, stored, standard analysis is needed because the sensitivity analysis will display the original values along with the new sensitivity values. Next, the user clicks on the "Sensitivity Analysis" option 156 at the top of the screen 167. A single pull-down menu option of create/modify/view analysis is displayed (not shown). Clicking this menu option yields a Sensitivity Analysis screen 226 shown in FIG. 29 and displaying available standard analyses 228 that apply at the level selected (domain) in the hierarchy, as well as any stored sensitivity analyses 230 that may apply. The Sensitivity Analysis screen 226 shown in FIG. 29 is the screen displaying the main options for viewing/modifying/creating a new analysis. Any standard analysis 228 conducted at any level above the level highlighted is listed because a standard analysis covers all levels at and below the selected level. The user creates a new sensitivity analysis by highlighting an "available standard analysis" 228 and clicking the "Create New Analysis" button 232. A Sensitivity Analysis Options screen 242 shown in FIG. 30 with the following options 244, with radio buttons, is displayed: modify quantification of a failure mode remove a subsystem replace a subsystem with a subsystem from another project remove a failure mode add a failure mode modify event sequence diagram. First, the user enters a sensitivity analysis name. Then the user selects an option, and clicks "Continue" 246. Subsequent subscreens (not shown) are displayed automatically. After a given option is completed (by completing the subscreens), the main sensitivity option screen 242 is again displayed. The user can then cycle through another change. Once all desired changes are made, the user clicks "Save and Run" 248 or "Save and Do Not Run" 259. The latter will create and save a sensitivity run that can be executed at another time. The Sensitivity Analysis Options screen 242, shown in FIG. 30, is the top level options screen for the main types of changes that can be made in an existing risk model for a project 63. It is important to use the "Enter Documentation" button 252 on the sensitivity options screen. QRAS 12 does not generate, automatically, documentation of the changes made for a given sensitivity run. It is the user's responsibility to document the temporary changes made so that one will know what the sensitivity results are based on. The analysis results for a sensitivity run are automatically displayed (not shown). The display format is almost identical to the analysis results format, except that both sensitivity quanitifications and rankings are displayed juxtaposed with the compared standard analysis. The other options on the main sensitivity screen 226 are straightforward. One can modify the already-made changes in a stored sensitivity analysis to create a new analysis 234; and options allow for viewing the results of a prior sensitivity analysis 236. An analysis can be deleted 238 or printed 240. In all cases, the user simply highlights the analysis name and clicks the appropriate button. 7. Tool Box The Tool Box contains stand-alone programs, either commercially-available or user-developed, that are useful in risk analysis. Two examples of programs in the area are to which links are supplied are: MATHEMATICA; and a BAYESIAN UPDATE PROGRAM. 8. Special Features There are 2 features that are important for creating or building up "projects" 63, and that were mentioned herein above. These are the "Copy/Paste" and the "Copy/Paste Special" features in the Edit menu 168. These features apply almost exclusively to the hierarchy 62. The foregoing features are not shown, but the functions thereof are discussed. Assume first that one wants to copy parts of an existing hierarchy internally within a given project. "Copy" and "Paste" can be used. The user highlights the element 64, or subsystem 66 (a failure mode 68 cannot be copied), and clicks on "copy." Next, the user highlights the element 64 or subsystem 66 below which the group is to be pasted and clicks "paste." The previously copied hierarchy structure will be pasted. If one wants to copy not only the hierarchy structure 62, but also the failure mode quantifications, OTIs, and ESDs, the user uses "Paste Special" rather than "Paste." The above features will thus allow duplication internally within a hierarchy. The phrase "below which" used in describing the copy and paste features is explained. If, for example, one wants to copy a another subsystem as part of an Element, highlight the Element; the subsystem will be copied as the last subsystem under the Element. One does not highlight a subsystem under the Element and seek to copy the source subsystem below this highlighted subsystem. Assume now one wants to copy parts (or all) of a hierarchy from one project to another distinct project. (Assume that both projects reside on the same computer, within the QRAS 12 directory). Noting that more than a single project can be "open" in QRAS, use the same method(s) noted above. In this way, new projects or parts of projects be directly added to a hierarchy to build-up a model. When using "Paste Special" between projects, the phases for the mission time line of the source and target projects should match (the system only requires that the numbers of the source project does not exceed the number of phases of the target project). The QRAS 12 will check and alert the user if the number phases of the source is greater than that of the target project. The QRAS 12 will not check to see that the actual phase times are identical. The target phases will be used. Because OTIs are defined at the subsystem level, the OTIs are transferred directly. Finally, suppose a user has created a project and wishes to transfer the project to another user on another computer. Attaching a project via e-mail is not satisfactory because a "project" is a folder containing approximately 125 files, and each would have to be attached separately. The user can, however, transfer the project folder via a File Transfer Protocol (FTP) program. In this way, any project can be transferred to any other user. (Code Q is establishing an FTP server site for this purpose). One can create a copy of a project to modify that does not contain a baseline, and hence does not have a locked hierarchy, mission time line, etc. First, create a new project. Then add mission phases to the new project (this is necessary because the Paste Special feature will check to insure an equal number of phases between projects). Finally, use Paste Special to copy the source project into the new project. "Copy/Paste," "Copy/Paste Special," and FTP are useful in dealing with system/subsystem upgrades. For example, once a system is modeled, a user can develop an upgraded subsystem. The original subsystem can be deleted and the upgraded subsystem can then be pasted into the model--to assess risk impact. 9. Failure Mode Quantifications are discussed in detail. Failure mode models are input in any of the following forms: 9.a. Point estimate and uncertainty Quantification is in the form of a point estimate and an uncertainty density function (with parameters specified) from Table 2. In some cases, parameters or percentile bounds are given to characterize the uncertainty distribution (so, in these cases, specification of a point estimate is not needed). 9.b. Function of physical variables Quantification is in the explicit form p=f(x.sub.1, . . . , x.sub.k) where p is a real-valued function in [0,1], the x.sub.i (i=1 to k) represent physical variables, each with an uncertainty density function (chosen from Table 2) which describes the probability of the allowed physical values, and k.ltoreq.3.
TABLE 2
Uncertainty Density Functions
and Parameters to be Specified
Density Specify the one of the following
Function parameters sets:
Uniform Mean and standard deviation; mean
and maximum; maximum and minimum;
5th and 95th percentiles
Normal Mean and standard deviation; 5th
and 95th percentiles
Lognormal Mean and standard deviation; mean
and error factor; median and error
factor; 5th and 95th percentiles
Triangular Mean and standard deviation;
(symmetrical) maximum and minimum
Beta Mean and standard deviation; 5th
and 95th percentiles; x.sub.0 and s.sub.0
parameters (failures, successes)
Gamma Mean and standard deviation; 5th
and 95th percentiles; shape (.alpha.) and
scale (.beta.) parameters
Weibull Mean and standard deviation; scale
(.alpha.) and shape (.beta.) parameters
Discrete Number of intervals (.ltoreq.20) and end
point for each interval to form a
histogram
The Density Functions shown in Table 2 are individually conventional and individually known, but the tools/options to enter the parameters and the uncertainties do not exist in other software packages. 9.c. Predefined functions for p Quantification, as in b., above, is in the form p=f(x.sub.1, . . . , x.sub.k) with k.ltoreq.3. But in this case standard "canned" functions are specified from the following list: (1) Logistic Regression Model: p=f(.sub.1, . . . , x.sub.k)=1/(1+1/exp(a.sub.0 +a.sub.1 x.sub.1, . . . , a.sub.k x.sub.k)). Specified are the variables, x.sub.1, . . . , x.sub.k, their associated a.sub.i parameters, and density functions (chosen from Table 2) for the x.sub.i. (2) Discrete function: ##EQU1## Specified are the intervals and the constant values on each interval. Also specified are density functions for each x.sub.i from Table 2. 9.d. Limit state function Quantification is in the form of a limit state function, g(x.sub.1, . . . , x.sub.k). This function has the property that g smaller than a limit value, c.sub.0 (a constant, usually 0), denotes failure (g.gtoreq.c.sub.o denotes success). The probability of failure is therefore p=Prob[g<c.sub.o ]. Specified are: (1) the function g; (2) the limit value, c.sub.o; and (3) the uncertainty density functions (chosen from Table 2) for each variable x.sub.i. (4) The uncertainty density around the point estimate for the probability of g<c.sub.o ; the options are: (a) Lognormal: probability of g<c.sub.o is assumed to be the median; user specifies the error factor. (b) Uniform: probability of g<c.sub.o is assumed to be the mean .mu.; user can specify min as k.mu., where 0.ltoreq.k<1. k is specified by the user. (c) Beta: with probability of g<c.sub.o assumed to be the mean .mu.; and N is specified, where N represents the sample size (as .mu.=f/N, where f is viewed as the number of failures. In this way the uncertainty expands or contracts, based upon the decreasing or increasing size of N, respectively). 9.e. Reliability for time interval [0,t.sub.o ] For a given failure mode, the probability of failure for the time period of operation is specified; e.g., probability of failure over 128 seconds for an SRB failure mode. Let R(t;.alpha..sub.1, . . . .alpha..sub.k) denote a reliability function, with parameters .alpha..sub.i, for example, R(t;.lambda.)=exp(-.lambda.t). Note now that if a subsystem functions for a time t.sub.o, the reliability at t=t.sub.o is simply R(t.sub.o ;.lambda.) and the failure probability is 1-R(t.sub.o ;.lambda.). This is the value specified, as a point estimate. The precise form of the reliability function, R(t;.alpha..sub.1, . . . , .alpha..sub.k), must be specified along with the uncertainty as a density function for each parameter .alpha..sub.i of R from Table 2. 9.f. Reliability function (exponential) Similar to e., above, but based on an exponential reliability function: R(t)=e.sup.-.lambda.t The mean failure rate, .lambda., is specified, along with an uncertainty about .lambda. from the density options in Table 2. 9.g. Reliability function (piecewise exponential) Quantification is in the form of a piecewise exponential reliability function: R(t)=e.sup.-.lambda..sup..sub.1 .sup.t for t.ltoreq.t.sub.1 R(t)=e.sup.-.lambda..sup..sub.1 .sup.t.sup..sub.1 e.sup.-.lambda..sup..sub.2 .sup.(t-t.sup..sub.1 .sup.) for t.sub.1 <t.ltoreq.t.sub.2 etc. Specified are: (1) Time intervals,: start and end times, t.sub.i, for each. Note that there is a limit of 3 time intervals. For each interval i, an uncertainty density for .lambda..sub.i is specified from Table 2. 9.h. Reliability function (Weibull) R(t) is given as: ##EQU2## where .alpha. is the scale parameter and .beta. is the shape parameter. Both .alpha. and .beta. are specified along with their respective uncertainty densities--chosen from Table 2. Summary In summary, the present invention QRAS 12 provides hierarchical decomposition of a system--from top level down to elements (these are "collections" of subsystems), to subsystems down to failure failures--that serves as both the visual organization and internal link to: quantification, event sequence diagrams, analysis, and sensitivity features. The QRAS 12 system is an integration of: Hierarchy; Mission Time Line (System and subsystem times of functioning); Failure Mode Quantifications and ensuing scenarios (Event Sequence Diagrams); Multiplicity/Redundancy/Dependency structure; an Analysis module; a Sensitivity Module; and a Stand-alone "Tool Box". Further, QRAs 12 is an integration of all the following in a single linked unit: a) system decomposition (with multiplcities, redundancies, dependencies); b) subsystem times of functioning and global top level system "phases" (mission time line); c) failure mode quantification and documentation (per element, subsystem, failure mode, and ensuing pivotal events); d) event sequence diagrams; e) analysis module (to allow, at any hierarchy level--and below, automatically--a presentation of the risk--by end state--with uncertainties; a ranking by failure mode, scenario, sybsystems based on mean, median, uncertainty); and f) an multiple sensitivity analyses based an analysis run, allowing changes in multiple parts of the original risk model. Further, QRAS 12 uses Event Sequence Diagrams (as distinguished from event trees (event trees are automatically generated)) and links these to the failure modes (equivalently, "initiating events."). In addition, QRAS 12 is user-friendly and provides a wide variety of quantification options--incorporating both standard reliability quantifications, standard and some nonstandard (e.g., "conditional") failure probability quantifications, and probabilistic fast probability integration (FPI) engineering design methods. Each option allows for inclusion of uncertainties in estimates. QRAS 12 includes a documentation feature integrated with the actual quantified model--and automatically calls a text editor for documentation input; and stores images. Thes features are easily accessed through the hierarchy and the applicable risk model module (e.g., Failure Mode Quantification). Further features included in QRAS 12 are summarized herein below. To facilitate speed and ease of analysis, simulations at the lowest possible level are generated only once and stored as a "Baseline." Other analyses then access this "Baseline"--rather than recreating all fundamental simulations again for each analysis. Analyses are stored and serve as a comparison for any sensitivity runs. That is sensitivity analyses are not viewed as independent runs--but are compared with an original stored analysis run. Also, the Baseline is not changed by a sensitivity run. It is fixed. To enable use by multiple engineers/analysts, the risk model (hierarchy, mission time line, quantifications, ESDs, Baseline, etc.) is "locked"--using a user-supplied password. Thus, no inadvertent changing of the primary model data can occur. This, in turn, ensures that all runs and results obtained are consistent across users. QRAS 12 includes a Risk Analysis Based Copy/Paste Feature which allows copying the hierarchy/quantifications/and event sequence diagrams (or just the hierarchy structure) both within a "project" and across "projects. A benefit is that this allows different users to develop different parts of a risk model (e.g. a subsystem of a larger system) and then another individual can assemble the entire model. (see below). Also, coupling this feature--across projects--with the use of File Transfer Protocol (FTP) allows a project created by any user at one computer machine to be used by another user on a different computer machine. The software architecture and flow of the QRAS 12 are organized so that both a skilled engineer/analyst or a high level manager can develop, access, and/or view the estimated risk values, uncertainties ranking and risk model documentation of a complex engineered system. The QRAS 12 provides a Mission Time Line which serves to partition the global system operation (into contiguous "Phases"), and to both communicate the operational time intervals (OTIs) for each subsystem and to allow (automatically) failure mode/reliability quantifications based on time--without reentering time values. The QRAS 12 design allows finer gradations of time intervals for quantification--by allowing Phases (contiguous, discreet intervals of system operation) and subsystem "Operational Time Intervals" (OTIs) that provide for tagging failure modes to particular time intervals for each subsystem within the large system Phases. Regarding statistical density failure mode quantification, the QRAS 12 allows specification of one ofa set of parameters that uniquely characterize the distribution; automatically, other sets of parameters that would also characterize the distribution are computed internally and displayed for the user. For uncertainty density computation and truncation by QRAS 12: when a user enters parameters to characterize an uncertainty distribution (which must lie in the interval [0,1]), software will determine what percentage of distribution must be truncated so that is in the [0,1,] interval and display message along with new computed mean value. QRAS 12 allows a copy/paste feature with event sequence diagrams. For multiplicity and redundancy: QRAS 12 uses a simple schema via the Hierarchy to indicate and internally compute risk for multiple "elements," "subsystems," and failure modes; in a similar hierarchy modification, QRAS 12 handles redundancy within the same type of unit. For multiplicity in QRAS 12: element, subsystem, or failure mode X is displayed in the Hierarchy as X(k), where k is the Multiplicity; Redundancy: subsystem X is displayed as X(k-of-n), where k out of n are required for success. Generally, QRAS 12 provides a unique method to handle multiplicities and redundancies for subsystems (and failure mode for multiplicities) by having a graphical entry of an integer into a system hierarchical decomposition. For dependency in QRAS 12: Based on design of combining the Hierarchy with a "fault tree-behind-the-hierarchy"--to handle dependencies between differing elements and/or subsystems; and the inclusion of a screen with ".beta..sub.cat =" and ".beta..sub.PermFailure =" to handle "Common Cause" beta factors. The analysis feature in QRAS 12 allows running software at a given level of the hierarchy and generating analysis results at that level and all lower levels. In addition, QRAS 12 provides the ability to store and recall prior analyses; similar feature for sensitivity analyses. QRAS 12 also provides the capability to perform Sensitivity Analyses, with features including: (a) --change failure mode quantification; (b) --change ESD; (c) --delete failure mode; (d) --delete subsystem; (e) --replace subsystem with subsystem from another project; (f) --modify redundancy, multiplicity, or common cause dependency beta value. The "Tool Box" Feature of QRAS 12: Allows stand-alone programs to be added to the software platform. Tool Box, itself, is a repository and functions as an interface to these stand-alone programs. Further, the QRAS 12 Platform is integrated with Mathematica. Also, QRAS 12 provides a Baseline with a capability to selectively delete parts of the Baseline and reestablish--without deleting remaining parts of the Baseline. Analysis computations for ranking risks by both individual scenarios or collectively by failure mode is provided by QRAS 12. QRAS 12 collects all scenarios initiated by a given failure mode. QRAS 12 also ranks risk by subsystem; in all rankings, the basis is by by median, by mean, or by uncertainty. QRAS 12 provides for determination of risk by various End States (e.g., catastrophic end state for system; permanent failure of a subsystem). QRAS 12 also provides risk ranking: by mean; median; uncertainty measures. Report Feature to printout the entire risk model (or selective parts) in total is provided by QRAS 12. In addition to printing all analysis results, QRAS 12 provides the capability to export electronic analysis files--for use in other reports or to transfer electronically. In QRAS 12, there is an organization of models by "Project." Each project is self-contained, and multiple projects may be opened and used together. The discrete, self-contained set-up of each project means that a project received from one user is directly usable by another user. QRAS 12 also provides an embedded text editor (for documentation) and uniformity of documentation via a fixed format text document that is called-up when the failure mode documentation feature is accessed. Further in QRAS 12 are Functional Subsystem Groupings, which is a feature to allow grouping various elements and/or subsystems and/or failure modes in the hierarchy viewed as performing a specific function (e.g., "propulsion") and determining the risk and risk rankings by this functional grouping. In QRAS 12, quantifications of failure modes allow not only absolute probabilities, but conditional probabilities. This is integrated with the multiple "Phases" time line. An event tree automatically generated by QRAS 12 from Event Sequence Diagrams, and can be viewed as part of the analysis module. While fault trees handle only a single type of "end state" failure for a given tree, and software links fault trees to event trees by tagging fault trees to the underlying event tree initiating and pivotal events (in the event tree, or ESD), QRAS 12 views fault trees at a higher level (rather than a lower level) and essentially uses the event tree (or ESD) scenarios to propagate up the fault tree. In this way, different types of "end states" are considered by QRAS 12. QRAS 12 also provides a "Time Slice" Feature: Given Phases, the design allows for analysis combining phases and by "slicing" between phases: e.g., given [start, stop].sub.1, [start, stop].sub.2, [start, stop].sub.3 as representing Phases 1, 2, 3 respectively, can specify a Start time within Phase 1 and a Stop time within Phase 3 and risks are computed for this period of a globally specified Start and Stop time. While current software can rank scenarios or failure modes, the QRAS 12 also allows ranking at higher levels--by subsystems, clusters of subsystems, functional groupings of subsystems. Also, because the Hierarchy allows multiple "indentations" (or subsystems of subsystems), one can group failure causes under a "subsystem" and thus rank a set of failure causes for a higher level failure mode in QRAS 12. The many features and advantages of the invention are apparent from the detailed specification and, thus, it is intended by the appended claims to cover all such features and advantages of the invention which fall within the true spirit and scope of the invention. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the invention to the exact construction and operation illustrated and described, and accordingly all suitable modifications and equivalents may be resorted to, falling within the scope of the invention.
|
| ||||||||||