The StateKind property specifies whether an error behavior state is considered to be a working state or a non-working state. A component can have multiple error behavior states that are tagged as working states.
StateKind : EMV2::StateKindEnum
applies to ({emv2}**error behavior state);
StateKindEnum: type enumeration (Working, NonWorking);
This property is underused. One should clarify the implication of error events, and repair/recover events.
In particular, E.8 (3) states that
(3) A component can show nominal behavior, represented by one or more working states, or it can show anomalous behavior, represented by one or more nonworking states. A component can transition from a working state to a nonworking state as result of an activated fault (error event) or due to the propagation of an error (error propagation) from another component. Similarly, recover and repair events can transition the component from a nonworking state to a working state. An error behavior state machine is a reusable specification that can be associated with one or more component type and implementation through a component error behavior subclause (section E.9) and a composite error behavior subclause (section E.11).
which is later restated in E.8.1. as
(1) The Error Model language distinguishes between three kinds of error behavior events: error events, recover events, and repair events. An error event instance represents fault activation within a component and will result in a state transition to an error state that represents the resulting failure mode and in an outgoing error propagation. Recover events represent recovery from a nonworking state to a working state. This is used to model recovery from transient errors. Repair events represent longer duration repair action, whose completion results in a transition back to a working state.
Questions:
[ ] What is the StateKind default value for the initial error state, see also issue #83 for a detailed discussion
[ ] Shall we enforce legality/consistency rules for on the value of StateKind property for source/target states pairs?
Resolutions (2/16/2023)
[ ] remove this property
[ ] rework the use of nominal/anomalous to something more consistent, e.g. nominal/off-nominal and make sure they are part of a glossary
E.14.1 (2) defines
The StateKind property specifies whether an error behavior state is considered to be a working state or a non-working state. A component can have multiple error behavior states that are tagged as working states.
This property is underused. One should clarify the implication of error events, and repair/recover events.
In particular, E.8 (3) states that
(3) A component can show nominal behavior, represented by one or more working states, or it can show anomalous behavior, represented by one or more nonworking states. A component can transition from a working state to a nonworking state as result of an activated fault (error event) or due to the propagation of an error (error propagation) from another component. Similarly, recover and repair events can transition the component from a nonworking state to a working state. An error behavior state machine is a reusable specification that can be associated with one or more component type and implementation through a component error behavior subclause (section E.9) and a composite error behavior subclause (section E.11).
which is later restated in E.8.1. as
(1) The Error Model language distinguishes between three kinds of error behavior events: error events, recover events, and repair events. An error event instance represents fault activation within a component and will result in a state transition to an error state that represents the resulting failure mode and in an outgoing error propagation. Recover events represent recovery from a nonworking state to a working state. This is used to model recovery from transient errors. Repair events represent longer duration repair action, whose completion results in a transition back to a working state.
Questions: [ ] What is the StateKind default value for the initial error state, see also issue #83 for a detailed discussion [ ] Shall we enforce legality/consistency rules for on the value of StateKind property for source/target states pairs?