Methodologies for Analysis of Dynamic System
In this section, GO method, digraph / fault graph, event sequence diagrams, Markov modeling, dynamic event logic analytical methodology and dynamic event tree analysis method will be discussed |
|
|
Qualitative Risk Analysis Methodologies
In the this section, we will deal with the qualitative methods used in risk analysis namely preliminary risk analysis (PHA), hazard and operability study (HAZOP), and failure mode and effects analysis
(FMEA / FMECA). |
|
Preliminary Risk Analysis
Preliminary Risk Analysis Preliminary risk analysis or hazard analysis is a qualitative technique which involves a disciplined analysis of the event sequences which could transform a potential hazard into an accident. In this technique, the possible undesirable events are identified first and then analyzed separately. For each undesirable events or hazards, possible improvements, or preventive measures are then formulated.
The result from this methodology provides a basis for determining which categories of hazard should be looked into more closely and which analysis methods are most sui |
|
Hazard and Operability Studies (HAZOP)
The HAZOP technique was developed in the early 1970s by Imperial Chemical Industries Ltd. HAZOP can be defined as the application of a formal systematic critical examination of the process and engineering intentions of new or existing facilities. To assess the hazard potential that arises from deviation in design specifications and the consequential effects on the facilities as a whole.
This technique is usually performed using a set of guidewords: NO / NOT, MORE / LESS OF, AS WELL AS, PART OF REVERSE, AND OTHER THAN. From these guidewords, scenarios that may result in a hazard or an ope |
|
Failure Mode and Effects Analysis (FMEA / FMECA)
This method was developed in the 1950s by reliability engineers to determine problems that could arise from malfunctions of military system. Failure mode and effects analysis is a procedure by which each potential failure mode in a system is analyzed to determine its effect on the system and to classify it according to its severity.
When the FMEA is extended by a criticality analysis, the technique is then called failure mode and effects criticality analysis (FMECA). Failure mode and effects analysis has gained wide acceptance by the aerospace and the military industries. In fact, the te |
|
Tree Based Techniques
In this section, fault-tree analysis (FTA), event-tree analysis (ETA), cause - consequence analysis (CCA), management oversight risk tree (MORT) and safety management organization review technique (SMORT) will be discussed.
|
|
Fault Tree Analysis
The concept of fault tree analysis (FTA) was originated by "Bell Telephone Laboratories" in 1962 as a technique with which to perform a safety evaluation of the Minutemen Intercontinental Ballistic Missile Launch Control System. A fault tree is a logical diagram which shows the relation between system failure, i.e. a specific undesirable event in the system, and failures of the components of the system. It is a technique based on deductive logic. An undesirable event is first defined and causal relationships of the failures leading to that event are then identified
Fault tree can be use |
|
Event Tree Analysis
Event tree analysis - consists of an analysis of possible causes starting at a system level and working down through the system, sub-system, equipment and component, identifying all possible causes. (What faults might we expect? How may they be arrived at?)
Assessment methods which allow quantifying the probability of an accident and the risk associated with plant operation based on the graphic description of accident sequences employ the fault tree or event tree analysis (FTA or ETA) techniques
Event Tree Analysis is a logical method of analyzing how and why a disaster could occu |
|
Cause-Consequence Analysis
Cause-consequence analysis (CCA) is a blend of fault tree and event tree analysis. This technique combines cause analysis (described by fault trees) and consequence analysis (described by event trees), and hence deductive and inductive analysis is used. The purpose of CCA is to identify chains of events that can result in undesirable consequences. With the probabilities of the various events in the CCA diagram, the probabilities of the various consequences can be calculated, thus establishing the risk level of the system.
|
|
Management Oversight Risk Tree (MORT)
Management oversight risk tree (MORT) was developed in the early 1970s, for the U.S. Energy Research and Development Administration as safety analysis method that would be compatible with complex, goal-oriented management systems. MORT is a diagram which arranges safety program elements in an orderly and logical manner. Its analysis is carried out by means of fault tree, where the top event is "Damage, destruction, other costs, lost production or reduced credibility of the enterprise in the eyes of society". The tree gives an overview of the causes of the top event from management oversights a |
|
Discussion and Conclusion
The tree-based methods are mainly used to find cut-sets leading to the undesired events. In fact, event tree and fault tree have been widely used to quantify the probabilities of occurrence of accidents and other undesired events leading to the loss of life or economic losses in probabilistic risk assessment. However, the usage of fault tree and event tree are confined to static, logic modeling of accident scenarios. In giving the same treatment to hardware failures and human errors in fault tree and event tree analysis, the conditions affecting human behavior can not be modeled explicitly. Th |
|
Performing the FMECA
Determination of the Causes of Failure : Causes of failure are listed in column 4 of the FMECA worksheet. In this study the failure causes are those that are specific to the Governance process. Failures in the Systems Engineering process become Governance failures only if Governance does not catch and correct them.
|
|
GO Method
The GO method is a success-oriented system analysis that uses seventeen operators to aid in model construction. It was developed by "Kaman Sciences Corporation" during the 1960s for reliability analysis of electronics for the Department of Defense in U.S
The GO model can be constructed from engineering drawings by replacing system elements with one or more GO operators. Such operators are of three basic types: (1) independent, (2) dependent, and (3) logic. Independent operators are used to model components requiring no input and the independent operators, require at least one input in or |
|
The ITIS Systems Engineering Model
The ITIS Systems Engineering (SE) Model is a high-level guide used for the development and deployment of systems within the NSA IT infrastructure. It was created in 2000, but was slow to be accepted due to its complexity. A subsequent effort created a companion to the SE Model which made it more understandable to the ITIS workforce. This companion became known as the Manager’s Guide to the Governance Process, and was internally published as a booklet under that title [Reference 1]. |
|
Identification of Failure Modes
The opportunities for failure of the Governance process occur at the 11 milestones of the Systems Engineering process.
The various governance boards are either directly or indirectly involved in the oversight of the milestones. Indirect involvement means that the milestone is accomplished “off stage”, i.e. not in front of the board. The board in this case merely reviews evidence that the milestone was successfully accomplished. An example is a statement of agreement signed by all stakeholders at a PDR that a preliminary design is satisfactory. Direct oversight means the board makes a va |
|
Accomplishment of Functional Analysis
The functional analysis is begun by setting the Governance function in context by relating it to the other functions of ITIS. At the highest level is the function “Provide an ITI” (Information Technology Infrastructure), which decomposes to the two functions shown in Figure 2.
The technical operation function of ITIS decomposes to five basic functions. These are: |
|
Definition of System (Product or Process) Requirements
The many processes of ITIS are interrelated, and a hierarchy diagram can be used to show the relationships. I have chosen to define a hierarchy of processes that I will follow in both my requirements and my functions. We start with a header that covers all of the processes of the ITIS organization. The next level covers the two major operational segments of ITIS: Business and Technical. Ignoring the Business Operations segment, we descend into Technical Operations where we find the Governance process residing with its peers. |
|
Preparing the System
Prior to performing the failure analysis we must make sure that fundamental aspects of systems engineering have been applied to the system or, in this case, process. We ensure that requirements are defined, functions are defined and arranged logically, and that there is a complete mapping between requirements and functions. In this section we will take care of these prerequisites. |
|
Safety Management Organization Review Technique
Safety management organization review technique (SMORT) is a simplified modification of MORT developed in Scandinavia. This technique is structured by means of analysis levels with associated checklists, while MORT is based on a comprehensive tree structure. Owing to its structured analytical process, SMORT is classified as one of the tree based methodologies.
The SMORT analysis includes data collection based on the checklists and their associated questions, in addition to evaluation of results. The information can be collected from interviews, studies of documents and investigations. Th |
|
FMECA Background
This paper presents a Failure Modes, Effects and Criticality Analysis of the ITIS Governance process. It is useful to set the stage by first showing the relationships of the various processes, including Governance, used to conduct the business of ITIS. A Functional Hierarchy Diagram is constructed in the next section to accomplish this. We will treat the collective set of processes as a system, with processes decomposing to sub-processes, etc. To track all of this activity, a model of the “Process” system was constructed in CORE. All of the rules of traceability to requirements, hierarchical |
|
TELL
FIRENDS
