CSC 402, Fall Requirements Analysis for Special Properties Systems Engineering (def?) –why? increasing complexity –ICBM’s (then TMI, Therac, Challenger...) –how? create system architecture –first job: analyze and modify requirements! criteria for its evaluation tradeoffs involving subsystems

CSC 402, Fall Components of Systems Safety (and other properties) “emergent” –the system is more than the sum of its parts “synergy” a real concept? –complexity shows up at the interfaces what does “divide and conquer” really accomplish? complex interfaces, simple modules simple interfaces, complex modules

CSC 402, Fall Software and Systems Engineering Software as “component” –embedded systems - software “control” Controlled Process Software Controller Inputs Outputs Uncontrolled Variables Actuators manipulated vars Sensors controlled vars

CSC 402, Fall Human as “Component” –human “control” - software “decision support” consider the system properties like “safety” –medical expert systems »or even patient databases –pilot interface to commercial airliner at system level: –what is known about the components –how can we reduce risks »relative to component parameters we can control

CSC 402, Fall Safety Analysis Safety as system property –software not “safe” or “unsafe” by itself safety relative to reliability? –what do we know about software reliability? »very, very little! »Parnas, Hamlet write about this extensively

CSC 402, Fall Steps in Safety Analysis Definition and Description of System Hazard Identification Accident Modeling Quantification of Risks Documentation of Results System Changes

CSC 402, Fall Feedforward control aspects –plans ahead to avoid and mitigate Feedback control aspects –uses accident information, when available when system not entirely novel

CSC 402, Fall Lots of Methods FMEA - failure modes effects analysis –based on failure modes of each significant system component AEA - action error analysis –human actions and failures are analyzed with respect to the system ETA - event tree analysis –postulate hazardous event, determine system responses FTA - fault tree analysis –postulate hazardous event, determine possible causes CCA - cause consequence analysis –combine ETA and FTA HAZOP - hazard and operability study –guide words (checklist approach) of “deviation analysis” - more of, less of, none, other WSA - work safety analysis –investigate working methods, machines and environment

CSC 402, Fall State Space Search Strategies Forward analysis –based on system structure –propogate failure of system elements forward Backward analysis –based on system structure –propogate backwards from postulated accidents Morphological analysis –concentrate on hazardous factors and potential targets

CSC 402, Fall Goals of the Search

CSC 402, Fall Applicability to Software? FTA: Leveson, Cha, 1991 Hazop: (Deviation Analysis) Reese, 1996 Others? (Want a Master’s Thesis topic???)

CSC 402, Fall Fault Tree Analysis Basic steps: postulate accident or undesired system output –root of tree determine necessary preconditions –draw as leaves with appropriate logical connectors –add probabilities if known

CSC 402, Fall Why Software FTA? Benefits: –Combats software state space explosion backwards technique reduces search space –only the events of interest are considered –Partial verification technique useful at many levels of abstraction –including requirements can be viewed as a structured walkthrough –with the power of the included logic

CSC 402, Fall –Learning and communication human interpretation of models is informative –Automatable there are some tools to draw and analyze

CSC 402, Fall Risky State Logical Connector and/or logical connector necessary precondx necessary precondx necessary precondx necessary precondx Recurse to leaves

CSC 402, Fall Comments Leveson, Cha paper: –work from system spec to software spec –work from software spec down to code to individual software constructs –based on safety-critical variable values –must know static program dependencies to take path »must also know how values may change »could be done like symbolic execution - path expressions

CSC 402, Fall Necessary Preconditions for FTA Need to know precisely: –necessary preconditions to get to any system state –probabilities for those conditions is this possible for software? fault tree value if it is not possible?

CSC 402, Fall Specification Support for FTA Basic support –precise and measurable requirements –analysis models that exhibit system behavior Full support –formal specifications state charts have been used as a basis for software FTA

CSC 402, Fall Classify the Technique? Static or Dynamic –execution as conceptual (walkthrough) –execution of “model” separate from product Redundancy in Requirements Analysis –what are the tradeoffs? –is this really a multi language approach to requirements and specification?