MQ RESUMEN CONSIDERACIONES INDUSTRIALES (2017)Resumen Inglés
Vista previa del texto
T-1 System Engineering
System: An integrated set of elements, subsystems, or assemblies that accomplish a defined objective
Characteristics of Systems: Interaction, Hierarchical, Emergent, Dynamic, Interdisciplinary
SYSTEMS ENGINEERING is:
- a methodical approach for the design, realization, technical management, operations, and retirement of a
- a way of looking at the “big picture” when making technical decisions
- an iterative process of top‐down synthesis, development, and operation of a real‐world system that satisfies
the requirements for the system
Systems Engineering: Top-down approach, Life-cycle
orientation, Emphasis on system requirements,
Interdisciplinary team approach.
Ejemplo: Se despieza X elemento en sus partes, se vuelve a montar. Se va de mayor nivel a menor nivel para luego integrarlosucede en cada proyecto.
Avionics Requirements: Reliability, Integrity, Real time, Fault toleranceavión no debe fallar y si ocurre debe mantenerse estable FAILURE CATEGORIZATION AIRCRAFT Salto de A a E es solo de certificación, documental, de demostrar que cumple la normativa ENGINEER REQUIREMENTS =a hierarchy of statements to go from high-level objectives to a detail level that can be implemented Well-stated requirements follow the next attributes: Necessary, Verifiable (con Test/Sistema de control), Attainable, Concise and unambiguous, consistent Why Requirements? - Provide early assurance that all top-level requirements are fully satisfied in the product, with traceability to where they are satisfied and clear visibility across teams into requirements allocation and cross-functional interactions.
- Prevent unintentional addition of cost - Establish clear responsibility for requirements implementation.
- Easily and quickly assess the impact of changes to requirements.
- Put a formal language and document the problem NUNCA SON UNA SOLUCIÓN, puede arrastrase o no a lo largo de un proyecto. En caso de cambioimportancia de la trazabilidad Requirement classification: System, Operational, Safety, Performance, Physical and Installation, Maintainability, Interface requirements SYSTEM LIFE-CYCLE PROCESS Traceability: Modify only the parts of the project that are affected by the change at high level; Show that a high-level requirement is fulfil at a design level; Show that all the requirements are used for verification; Control of the modifications of the requirements that affects our sub-system Verification: Are we doing the system right? (¿Se han hecho los pasos correctos?)Ensure that each step in the process yields the right product Validation: Are we doing the right system? (¿Que se ha pedido?) Ensure the product will satisfy the functional and other requirements The (wrong) Project Lifecycle 1.Project Initition 2.Wild Enthusiasm 3.Disillusionment 4.Chaos 5.Search for the Guilty 6.Punishment of the Innocent 7.Promotion of the Non-participants 8.Definition of the Requirements SYSTEM LIFE-CYCLE PROCESS T-2 Safety Assessments Process Fly-fix-fly: analysis of accidents and feedback of experience to design and operation Fault Hazard Analysis: Trace accidents (via fault trees) to components, Assign criticality levels and reliability requirements to components, Specify development procedures (DO-178B…) FAIL SAFE DESIGN: “No single failure or probable combination of failures during any one flight shall jeopardize the continued safe flight and landing of the aircraft” Design integrity and quality, Redundancy, Isolation (so failure in one component does not affect another), Component reliability enhancement, Failure indications, Specified flight crew procedures, Design for checkability and inspectability, Failure containment, Damage tolerance (Systems surrounding failures should be able to tolerate them in case failure cannot be contained), Designed failure paths (Direct high energy failure that cannot be tolerated or contained to a safe path), Safety margins or factors, Error tolerance (Design so human cannot make mistakes or errors are tolerated) Safety Assessment Process Guidelines and MethodsARP 4761 (FHA: Functional Hazard Assessment, PreSSA, SSA: System Safety Assessment, FMECA: Failure Mode, Effects and Criticality Analysis, FTA, DD: Dependence Diagrams (ALTERNATIVE TO FTA, PARALLE=AND, SERIES=OR), MA: Markov Analysis, CCA: Common Cause Analysis, (Verify the independence of all the events in the FTA/DD in the real implementation)) FTA: FAULT TREE ANALYSIS What is it? - a top-down approach to failure analysis, starting with a potential undesirable event (accident) called a TOP event, and then determining all the ways it can happen - it determines how the TOP event can be caused by individual or combined lower level failures or events - The causes of the TOP event are “connected” through logic gates - is the most commonly used technique for causal analysis in risk and reliability studies Why FTA is carried out? - To exhaustively identify the causes of a failure, the weaknesses in a system, effects of human errors and effective upgrades to a system - To assess a proposed design for its reliability or safety - To quantify the failure probability and contributors - To optimize tests and maintenances Questions that FT can answer – qualitative: Check if the top-level event is reachable; Finding all the minimal cut sets causing the top-level event; Check if there are single points of failure, i.e., minimal cut sets of order one Questions that FT can answer – quantitative: Calculate the probability of top level event to occur; Check if there is any cut set with probability higher than 10-7; List all minimal cut sets with probability higher than 10-7 Methodology (Rules) 1. The “Immediate, Necessary & Sufficient” Immediate=Closest in space, time and derivation of the event above; Necessary=There is no redundancy in the statement or gate linkage. The event above could not result from a sub set of the causal Sufficient=The events will, in all circumstances and always, cause the event above 2. The “Clear Statement” Write event box statements clearly, stating precisely what the event is and when it Occurs 3. The “No Miracles” If the normal functioning of a component propagates a fault sequence, then it is assumed that the component functions Normally 4. The “Complete-the-Gate” All inputs to a particular gate should be completely defined before further analysis of any one of them is Undertaken 5. The “No Gate-to-Gate” Gate inputs should be properly defined fault events, and gates should not be directly connected to other gates 6. The “Component or System Fault?” The Four Necessary Steps to Begin a Fault Tree: Define the focus of the FTA, the scope of the FTA, the basic causal events to be considered (the resolution of the FTA) the initial state of the system OR=IF ANY OF THE INPUT EVENTS OCCUR AND=ALL THE INOUT EVENTS OCCUR AT THE SAME TIME Some Boolean Laws - Commutation: A + B = B + A A * B = B * A - Association: ( A + B ) + C = A + ( B + C ) ( A * B ) * C = A * ( B * C ) - Distribution: A * ( B + C ) = A * B + A * C A+(B*C)=(A+B)*(A+C) - Abortion: A + ( A * B ) = A A * ( A + B ) = A - Identity: A + A = A A * A = A Minimal Cut Sets: - A minimal cutset (msc) is a smallest combination of primary events, or basic events, causing the top event - All the primary events need to occur to cause the top event - Each mcs is thus a causaul-combination, i.e., a combination of primary events - The set of mcs directly link the top event to the primary events - The complete set of mcs provides the complete set of causes of the top event The minimal cutsets provide key qualitative information: - Directly link the top event to the primary events, or basics events - The minimal cutset (mcs) size is a qualitative ranking of the causal-combination - A single element mcs identifies a single cause of the top event - The component types in the mcs also provides a qualitative ranking of the causal combination - Redundant components in a mcs can be susceptible to a common triggering cause ...