Error Model Annex Revision

Transcription

1 Error Model Annex Revision Peter H Feiler phf@sei.cmu.edu Jan 2011

2 Goal A core set of reliability concepts and error types Interaction of systems with nominal behavior and threats in the form of defects, faults, misbehavior, violated assumptions resulting in error propagations (hazards) Anomalous and threat mitigation behavior of a system or a system component Composability of error model in the system hierarchy Avoid global visibility into error states Error model representation improvements Add error semantics to stochastic communicating state machines Properties on all error model concepts Error types and attributes Clean separation of error propagation, error behavior, composition Explicit propagation and observation 2

3 Approach Focus fault types (fault ontology) Focus on fault propagation External fault interaction with other components Focus on fault behavior inside component How the component deals with its internal faults & incoming propagations Focus on component hierarchy System fault behavior in terms of subsystem fault behaviors Focus on interaction between fault management specification & management implementation Detection (heart beat, output monitoring) Containment (space partition, time partition) Restoration action: Recovery/repair behavior (replacement, extrapolation) Isolation higher level symptom decomposed into lower level causes 3

4 Error Type Definitions & Type Hierarchy Error types defined in terms of other error types establish a type hierarchy: ObservableOccurrenceError: error type { Omission, Commission}; ObservableTimingError: error type { Early, Late}; ObservableValueError: error type { Bad_value, Imprecise_value}; ObservableStreamError: error type {ObservableOccurrenceError, ObservableValueError, ObservableTimingError, Wrong_rate, Variable_rate}; Error types can be members of multiple error types: ObservableAccessError: error type {ObservableOccurrenceError, ObservableValueError}; Error types may be leafs in the type hierarchy: Omission : error type; 4

5 Outline Error types Error propagation specification Component error behavior specification Fault occurrence & Repair Compositional error models 5

6 Propagated Types of Errors Incoming feature Types of incoming Errors Types of incoming Errors Bidirectional feature Types of outgoing Errors System Outgoing feature Types of outgoing Errors Errors may be propagated along explicitly modeled component interaction relationships expressed by associating error types with features and platform resource categories indicating outgoing and incoming error types Errors may be observable without an explicitly modeled component relationship Expressed by associating observable and observed error types with components Types of incoming Errors Platform Resources Types of outgoing Errors 6

7 Observable Error States & Error Propagation Components have an error behavior state described by its error behavior state machine These error states get mapped into observable error states that are propagated to other components. These observed states represent propagated errors that may affect the error behavior of the recipient component. ErrorFree PowerGlitch PowerLoss NoError LimitedService Dead Error Behavior State Machine p NoService Propagated Errors 7

8 Error Propagation Behavior of Component A component may be the source of a propagated error Represents error propagations due to intrinsic errors Expressed by an error source declaration error source outport1[late]; A component may be the sink of a propagated error Represents masking of a propagated error by the component Expressed by an error sink declaration error sink inport1[late]; OR error mask inport1[late]; A component may pass on a propagated error Represents propagation of an error as the same type or a different Expressed by an error path declaration error path inport1[early] -> outport1[early]; error path inport1[late] -> outport1[omission]; error path processor[deadline] -> out1[novalue]; Propagated Errors Sink of incoming errors Incoming feature Source of outgoing errors Outgoing feature NoError Incoming feature Path of propagated errors Outgoing feature LimitedService NoService 8

9 Error Model Annex Subclause Constructs The Error Propagations statement associates error types with features & resources Allows error types to be named in rules without qualifying their identifier with the name scope (acts as a with and renames). System ControlSystem Annex error_model {** error propagation inport1: in error SWErrors::ObservableStreamError; rwaccess1: in out error SWErrors::ObservableUpdateError; Propagation rules error sink inport1[early]; **}; End ControlSystems; 9

10 Error Propagation Behavior No default error propagation rule This allows us to determine whether an error was intended to be propagated This also means to catch-all otherwise rule Short-hand for explicit any-to-all propagation behavior declaration Passing on an error type Error path any[early] -> all[early]; Actual error types are preserved Error path any[observablevalueerror] -> all[observablevalueerror]; An error type is mapped to another error type Error path any[late] -> all[omission]; Mapping of all incoming error types: special keyword vs. super error type inport1[all] vs. inport1[observablestreamerror] Mapping an Error type with subtypes The outgoing type must be a leaf error type Error path any[observabletimingerror] -> all[omission]; The recipient does not distinguish between subtypes Error path any[observabletimingerror] -> all[observablestreamerror]; 10

11 Error Propagation Behavior - 2 Error propagation rules & ordering Allow overlapping rules Rule ordering determine interpretation order General guidance: from specific to general Feedback to user about override due to overlap Require non-overlapping rules No rule ordering needed No catch-all otherwise rule Explicit specification of all handled error types Checking for coverage Coverage of incoming error types with respect to propagated error type specification Coverage of outgoing error types with respect to propagated error type specification Completeness of propagated error type specification(?) Need for error type to represent unknown error types (predeclared type?) 11

12 Error Propagation Behavior - 3 Error propagation rules & flow specifications Consistency between (complete set of) flow specifications and error propagation paths 12

13 Connecting Component Error Propagation Behaviors Propagation paths are determined by feature connections & deployment bindings Matching of outgoing and incoming error types Take into account error type hierarchy Observations & propagations Along explicit relations (connections, bindings) Ability to define additional relations in base model rather than error model 13

14 Conditional Error Propagation Rules Allows for specification of mitigation strategies Conjunctions on incoming features Inport1[late] vs. Inport1[late] and inport2[early] Unrelated inputs vs. related inputs Need for X OrLess and X OrMore operators? Not operator What does late mean? Early, other error types, or no error? Is NoError the same as ObservableStreamError (representing all incoming error types on an feature? Disjunctions vs. multiple rules Choice not affected by overlapping rule semantics Disjunctions on features Disjunctions on error types Represented by error super type Explicit list for subset of super type Consider set difference: error super type \ { error type1, error type2} 14

15 Conditional Error Propagation rules - 2 Need for ability to test for NoError on a port Inport1[late] vs. Inport1[late] and inport2[noerror] Built-in testable NoError Need to test for UnknownError? (Different name) Myron: Unanticipated errors (all others) assumptions made at higher level may be violated Unknown: open world assumption safety applications have a need for open world Diagnostics: feedback into the design process (root cause of error incomplete hazard analysis) Conditionals and coverage Precedence & hierarchy of propagation rules Example: No power -> no data Generic error model associated with core thread state machine Need to customize generic error models? Extends of error models Customization when error model is applied to component Dependency: depends on Example: processes depend on a database Guards: name mapping for reusability; propagation conditions as part of propagation specification 15

16 Outline Error types Error propagation specification Component error behavior specification Fault occurrence & Repair Compositional error models 16

17 Component Error Behavior Specification Internal to component (aka Error Model Implementation) Realizes error propagation behavior specification of component Associated with type or implementation Represent intrinsic error events Represent component error behavior as state machine State transition and error propagation behavior Represent repair events & actions Question: Different component implementation may have different error propagation behavior. Different error models for different component implementations. Possible need for different error models for different instances. Property mechanism already supports this. Mode-specific property values on the error model associated with a component or system. Mode-specific intrinsic errors and error state machines. Need for mapping from error state in one mode to error state in another mode when mode transition occurs. Operational readiness: helicopters in different states of readiness. Does operational mode relate to composite models while component error models are not mode specific. 17

18 Intrinsic Error Event Specification Error events declared with error types Known by error event name: DivideByZero: error event; Implicit error event type Event type: error event SWErrors::DivideByZero; Event name & type: DivideByZero: error event SWErrors::DivideByZero; Stochastic occurrence property and other properties on event Use of core property mechanism Explicit specification of condition in terms of application data Error triggering conditions As mode transition conditions on component state variables (see Noll example) In a constraint annex: predicates on in/out ports, component state (runtime properties) Implicit constraint on properties (e.g., measurement units on data through ports) Specification of errors in error model separate from specification of what you want them to build. Need to establish consistency between the two specifications Need the ability to explicitly specify the detection of errors Vangelis: need for merging mode, behavior & error state machines 18

19 Error Characteristics to be Reflected Distinguish error event & repair event Errors Internal & propagated: mapping of state to propagation Intentional & unintentional propagation: Explicit documentation of internal/propagated Detected, reported, mitigated, propagated: Mapping into core model events Myron: properties: initiating event, working/non-working state, describe the event (comment/description), severity (4 levels in MIL standard). Modeling of transient error events Specified via property on error event What information should be specified? Reflected in error state machine through appropriate (repair) transition 19

20 Error Characteristics as Properties Error types can have properties: Activation: error type { ErrorKind => Permanent;}; Probability of a property value: Ana had to use transient error states. Activation : error type { Occurrence => lh Poisson; ErrorKind => (Permanent with ph, Transient otherwise);}; 20

21 Error State Machine Examples Transient error states (activation fault, detection end) vs. permanent (working) states Error states with equivalent mode states (in repair) 21

22 Error Behavior State Machine Specification Error Behavior States Handling of permanent/transient error events Transient and working states: specified via property Transient states Must have one enabled outgoing transition (must have transitions with probabilities adding to 1) Working states ErrorFree state and error states (working state with property to indicate the degree of work it is able to do) Error free state: only repair event triggered incoming transitions (consistency checking?) Vangelis: use of state variables? Initial state: always error free? Degraded state is possible as initial state Initial state and activation resumption in initial state vs. last state (handled as property for modes) Multiple error free states? See working states Observable error states Association of outgoing error propagation as mapping rather than self transition 22

23 State Transitions & Error Propagations A two-step process Incoming propagated errors & error events trigger state transition All error events must be handled by state transitions Incoming errors may affect the error behavior state Outgoing error propagation based on resulting error behavior state Pass through of incoming error propagations without affecting error state? Modeler should have the option to specify either way. Need to be precise in semantics of which state the out guard refers to. Discussion about assumptions 23

24 On Guards In Guards Define mapping of outgoing error propagation names to incoming error propagation names Allows error models for interacting components to be defined independently Define a named condition under which an error state transition occurs Condition includes out propagations and error states of connected components Transition specifies an OR condition of error events and named conditions Define masking of incoming error propagations 24

25 On Guards - 2 Out guard Unconditionally pass through incoming error propagations Condition on outgoing error propagation based on own error state, error state and outgoing error propagation of connected components Conditionally mask error states or error propagations of connected components Event guard Mapping of error state into an event in the core model Transition guard Condition on mode transitions 25

26 Interface with Behavior Annex Reference to Vangelis talk on error model repository Error model conditions mapped into events (triggers) vs. behavior annex specification of the fault monitoring functionality Fault detection & propagation behavior can be for hardware as well (e.g., internal to device and propagated through error or event port) Example issue: elevator spec distinguishes transient and permanent errors, while implementation did not. Myron: cannot separate safety analysis from system design. Need to ensure consistency between the two. Abstraction of the implementation. 26

27 Outline Error types Error propagation specification Component error behavior specification Fault occurrence & Repair Compositional error models 27

28 System Composition & Integrated Whole External Controls System Flow Interaction System System System Input Peer Peer Peer Output P&OSS P&OSS P&OSS Properties & Internal Resource Control Internal Control Internal Resource Properties & Composite System State Observable System State External Resources 28

29 Composite Error State Machine Derived (composite) error states System components with error models Represents system state in terms of interacting component states Reliability/availability: in terms of one of the composite system states Conditions include statements like 2 ormore, 2 orless 29

30 Composite Error State Machine Error State machines as Abstraction To achieve tractability Declared separately from component error state machines Tracability to component error state machines & relation to dervied error states Tractability: hierarchical composition. Validate lower level model, and then use 2-out-of-3 model higher level. Myron: m out n systems. Numerical expressions. 30

31 Outline Error types Error propagation specification Component error behavior specification Fault occurrence & Repair Compositional error models 31

32 Error Behavior and Fault Management Fault occurrence and detection Repair/recovery occurrence SysB 1l Mode u Fault state SysA 1 orless -> mask u d S1 1l Fault Mgr Logic 1l-l2 switch u d 2l S2 Failure Detection Heart beat nd ok Ndt Ndp ok nd ok ok Fault propagation Sy21 Fault mgnt spec Recovery behavior 32

33 Coordination Between Error Behavior & System Behavior Objectives: Impact of error state on system behavior Modeling of repair activity: start, completion, repair failure Error States & Modes Mapping of error states into mode transition events Mapping of mode transitions into error behavior transition events Error states & Behavior specifications Objective: modeling of faulty behavior, of repair activity Error states as behavior conditions Working states In error model vs. in system state (mode) 33

34 Repair Events & Behavior Represent repair events Stochastic occurrence property Traceability to repair event trigger in actual system Represent different repair behavior Repair action with duration Repair agent as shared resource Repair parts as consumable resource Traceability to repair action in actual system architecture 34