Error-Model Annex v2 -Functional Hazard Assessment Analysis - FHA

A technique known as Functional Hazard Assessment (FHA) - not to be confused with Fault Hazard Analysis (see FAA System Safety Handbook) - is defined as part of SAE ARP4761. It is a systematic examination of systems and subsystem functions to identify and classify failure conditions of those functions according to their severity.

We support this process by working with specifications of the system or subsystems of interest expressed as component type descriptions for all component categories in AADL ranging from system and process to processor and device. We will than attach information relevant to an FHA through EMV2 subclauses and property associations.

We use the EMV2 subclause to declare for each component the relevant outgoing error propagations and identify those outgoing error propagations that are error sources. In the error source declaration we may identify the error source as an error state or as an error type set (set of type tokens). Those are the entities that represent potential hazards to other components or the environment.

EMV2 includes a set of properties that are defined in the property set EMV2. Three such properties are :

  1. Severity
  2. Likelihood
  3. Hazard

They allow modelers to provide descriptive hazard in-formation to the model. The property values are associated with error sources or outgoing error propagations of components. They are declared in the properties section of EMV2 subclauses. They can be declared for component types or implementations; in this case they apply to all in-stances of components of this type. Or they can be declared for specific subcomponents; in this case the hazard description can be specific to the context of the subcomponent (component instance).

The path in the applies to clause of the property association is used to identify the specific target of the hazard description. The path is a (.) separated list of identifiers. The path may start with zero or more subcomponent identifiers starting with a subcomponent in the component whose error annex subclause contains the property association. The path is followed by a error propagation identifier or error source identifier and optionally an error type identifier. The error propagation or error source must be of the last subcomponent in the path or the component classifier (type or implementation) that contains the error annex subclause.

The Error Model V2 Annex standard defines severity and Likelihood as follows:

The Severity and Likelihood from the standard EMV2 are the following:


Severity : inherit aadlinteger applies to (all);

Likelihood : inherit enumeration (A, B, C, D, E) applies to (all);

MIL-STD-882 and ARP 4761 define separate sets of labels for different severity and criticality levels. We make those available through two separate property, as shown below.

The Severity and Likelihood for MIL-STD-882 are the following:

property set MILSTD882
  is

Severity : inherit enumeration (Catastrophic, Critical, Marginal, Negligible) applies to (all);
Likelihood : inherit enumeration (Frequent, Probable, Occasional, Remote, Improbable) applies to (all);

end MILSTD882;

The Severity and Likelihood for ARP 4761 are the following:

property set ARP4761
  is
  
Severity : inherit enumeration (Catastrophic, Hazardous, Major, Minor, NoEffect) applies to (all);
Likelihood : inherit enumeration (Probable, Remote, ExtremelyRemote, ExtremelyImprobable) applies to (all);

end ARP4761;

The Hazard property is defined in the property set EMV2 and consists of the following record fields:

Processed modeling patterns

The following modeling patterns are considered when generating the FHA:

Each processed artifact must have the following properties attached:

Example model

The following model illustrates an example hazard specification. The Hazard property is associated with the error behavior state that is the error source. Such hazard specifications are characterized with severity and criticality. Other models can be found on our github public example repository: https://github.com/osate/examples.

  device PositionSensor
    features
      PositionReading: out data port ;
    flows
      f1: flow source PositionReading {
        Latency => 2 ms .. 3 ms;
        };
    annex EMV2 {**
        use types ErrorLibrary;
    	use behavior ErrorModelLibrary::Simple;
    	error propagations 
    		PositionReading: out propagation  {ServiceOmission};
    	flows
    	
		 ef1:error source PositionReading {ServiceOmission} when Failed;
	end propagations;
	properties
	-- property is associated with the error behavior state as the source of an error source.
	-- it uses the generic version of the Hazard property
		EMV2::severity => 1 applies to ef1.Failed;
		EMV2::likelihood => C applies to ef1.Failed;
	EMV2::hazard => 
	[	crossreference => "1.1.1";
		failure => "Loss of sensor readings";
		phase => "all";
		description => "No position readings due to sensor failure";
		comment => "Becomes major hazard, if no rdeundant sensor";
			]
			applies to ef1.Failed;
    **};
  end PositionSensor;

Functional Hazard Assessment report example

From the previous model, we can automatically generated the report, as shown below. Catastrophic and critical hazards are shown as included in a Functional Hazard Assessment (FHA) report. The remaining hazards remain in the model for safety analysis activities in later phases.

The set of hazards to be reported is determined as follows: