Back in September of 2017, Daniel represented DISTek and presented a paper at the SAE Aerotech conference, held in Fort Worth, Texas. The paper was entitled: A Means of Assessing the Entire Functional Safety Hazard Space and below is a summary. You can get a copy of the full paper by clicking here.
Safety is a challenging status to achieve and maintain, thus the need for the guidelines that collectively fall under the heading of Functional Safety (FS). DISTek has always been conscience of safety as it applies to the products developed for our customers. This includes implementing the various requirements and guidelines associated with Functional Safety, as expressed in documents, such as ISO 25119.
One common FS requirement is the need to initially assess the potential hazards that can arise in association with the future system under construction. The industry already uses various Functional Hazard Assessment (FHA) techniques, including two of the more common FHA techniques, Fault Tree Analysis (FTA), and Failure Modes and Effects Analysis (FMEA). FTA is a top-down approach, where the assessor starts with an undesired event and breaks down the identifiable combination of (or single) failures that can lead to that undesired event. FMEA is bottom-up, starting with a single failure and then assessing that failure’s impact on the system.
In both approaches, the process requires assessing what can go wrong to create a set of hazard scenarios, which are subsequently addressed by designing and implementing safety functions. Ultimately, the goal is to assess as many scenarios as possible.
However, this begs the question, when do we know that we have assessed enough of the hazard space? Of course, one can’t possibly anticipate every hazard, yet the goal is to systematically assess as much as possible. This became the motivation for the Aerotech paper.
Hazard Space Analysis (HSA) was proposed in the paper, a technique that assesses a greater percentage of the hazard space by sacrificing scenario detail. In other words, rather than assessing entire detailed scenarios, our approach computationally generates a large number of concise hazard rules, which can be quickly assessed for relevance, severity, and occurrence probability. Our approach is subtractive; we start with a large number of rules, representing a large percentage of the hazard space, and trim down its size. This is in contrast to the typical additive approach, where the hazard space is “filled” by adding one hazard assessment at a time.
To start with a large percentage of the hazard space we computationally generate every possible hazard rule based on the Cartesian product of the elements that defines a hazard rule. A hazard rule is defined as a transition from a system’s Operational Situation (OS) to a Hazard State (HS) as caused by one of several possible classification of Hazard Causes (HC). These three elements are combined into the definition of a hazard rule, expressed as HC: OS à HS, which says that the system transitions from an Operational Situation (OS) to a Hazard State (HS), when a Hazard Cause (HC) occurs. HC can be an Environmental State, an operator’s Off-Nominal Behavior, or a Component Failure. For example, if OS is CarTurnRight, the HS is SkiddingIntoADitch, and the HC is IcyRoads, then the hazard rule becomes IcyRoad: CarTurnRight à SkiddingIntoADitch, which reads: An icy road can cause a car turning right to skid into a ditch. Each of the three elements OS, HS, and HC can each be a long list {. . .} of options, such as:
List of Operational Situations (OS) = {CarTurnRight, CarTurnLeft, CarMoveForward, etc.}
List of Hazard States (HS) = {SkiddingIntoADitch, Rolling, RunningIntoObstacle, etc.}
List of Hazard Causes (HC) = {Icyroad, WetRoad, LargePotHole, etc.}
Combining these three lists using the Cartesian product, results in a long list of hazard rules such as:
Hazard rule 1 = IcyRoad: CarTurnRight à SkiddingIntoADitch
Hazard rule 2 = WetRoad: CarMoveForward à RunningIntoObstacle
Hazard rule 3 = LargePotHole: CarMoveForward à Rolling
Hazard rule N = etc.
Note that while the probability of a pothole causing a car to roll may be considered low, or even irrelevant and unlikely, the fact is that this potential scenario was generated, allowing the engineer to assess whether this hazard rule is worth addressing. Regardless of its occurrence probability, the scenario is part of the hazard space and may have been overlooked, when using an additive approach.
The process of generating all the possible hazard rules within a given hazard space begins with the engineer compiling separate lists of OS, HS, and HC. The computer then generates every possible combination of OS, HS, and HC in the form of HC: OS à HS. Notice that the human performs the easier task of compiling the elements OS, HS, and HC, while the computer does the harder task of generating the Cartesian product of those elements into a larger set of hazard rules. This reduces the cognitive load on the engineer, since he/she does not have to conceive every complete hazard scenario that may exist.
The bottom line is that a larger set of hazard scenarios can be assessed by the engineer, thus covering a larger percentage, if not all, of the hazard space. What this means to DISTek customers is that when performing hazard assessments, DISTek can now expose a higher percentage of hazard scenarios, even if that means simply providing the customer with a set of hazard rules, which the customer can use at their discretion.
