Safety

Definition

Safety

1) the defensibility quality factor representing the degree to which:

• Accidental (i.e., unplanned and unintended but not necessarily unexpected) harm to valuable assets is prevented or reduced in probability or severity
• Safety incidents (i.e., accidents and near misses) are detected and reacted to
• Adaptations are made to minimize future accidental harm

2) the degree of freedom from:

• Accidental harm to valuable assets including people, property, and the environment
• Accidents that cause harm
• Hazards that may cause accidents
• Safety risks due to hazards

Classification

As illustrated in the preceding figure, Safety is part of the following inheritance hierarchy:

• Type: Abstract
• Superclass: Defensibility
• Subclasses:
  • Health Safety
  • Property Safety
  • Environmental Safety

Responsibilities

The typical responsibilities of Safety are to:

• Model the degree to which valuable assets are defended from accidental harm.
• Support the analysis and specification of safety requirements.

Subfactors

As a kind of defensibility, security can be decomposed into the following two hierarchies of safety subfactors:

• Defensibility Problem Subfactors.
  Defensibility problem subfactors represent the kinds of problems from which defensibility (including safety) is intended to defend systems:
  • Harm.
    Harm (a.k.a., loss) is any significant negative consequence to a valuable asset:
    • Accidental Harm.
      Accidental harm is harm to valuable assets resulting from accidents.
  • Incidents.
    An incident is any unplanned, unintended, unauthorized, (but not necessarily unexpected) event or series of related events that could cause unintentional harm to one or more valuable assets:
    • Safety Incidents.
      Safety incidents are incidents that could cause accidental harm to one or more valuable assets:
      • Accidents are safety incidents that cause accidental harm to valuable assets.
      • Near Misses (a.k.a., close calls) are safety incidents that do not cause accidental harm to valuable assets.
  • Dangers.
    Dangers are one or more conditions, situations, or states of a system that in conjunction with conditions in the environment of the system can cause or contribute to the occurrence of one or more related incidents:
    • Hazards.
      Threats are dangers that can cause security incidents (e.g., the existance of viruses and malicious attackers with means, motives, opportunities).
  • Risks.
    Risk is the magnitude of the potential harm to a valuable asset occurring due to a danger. A typical conservative measure of risk is the sum (over all dangers) of the products of (1) probability that the danger will cause harm multiplied by (2) the largest credible negative impact of the harm on the asset (i.e., its criticality, severity, or damage). Using the mathematics of conditional probabilities, the probability that a danger will cause harm can be calculated (estimated) as the products of the following terms: (A) the probability that the dangerous system-internal conditions exist multiplied by (B) the probability that the dangerous system-external conditions exist given that the dangerous system-internal conditions exist multiplied by (C) the probability that an incident will occur given that the danger exists multiplied by (D) the probability that the incident will cause the harm given that the incident occurs.
    • Safety Risks.
      Safety risks are the risks due to hazards resulting in accidents causing harm to valuable assets.
• Defensibility Solution Subfactors.
  Defensibility solution subfactors represent the kinds of solutions that defensibility (including safety) is intended to provide:
  • Protection.
    Protection is the defensibility subfactor representing the degree to which a system or component prevents accidental harm, threats, safety incidents, and safety risks.
  • Detection.
    Detection is the defensibility subfactor representing the degree to which a system or component detects the occurrence of accidental harm, threats, safety incidents, and safety risks.
  • Reaction.
    Reaction is the defensibility subfactor representing the degree to which a system or component responds to the occurrence of accidental harm, threats, safety incidents, and safety risks.
  • Adaptation.
    Adaptation is the defensibility subfactor representing the degree to which a system or component modifies itself as the result of the occurrence of accidental harm, threats, safety incidents, and safety risks to avoid them in the future. In addition to the common defensibility reaction subfactors, it includes:
    • Safeguard Improvement

The following figure illustrates the decomposition of defensibility and therefore safety into the following two hierarchies of subfactors:

The following figure illustrates some of the different kinds of harm to valuable assets:

The following figure illustrates some of the different kinds of incidents:

The following figure illustrates some of the different kinds of dangers:

The following figure illustrates some of the different kinds of risk:

Measures

Safety is typically measured in terms of:

• Accidental Harm:
  • [Existance | number | average number] of [injuries (of a specific severity) | illnesses(of a specific type and severity) | deaths] [caused | permitted | N/A] per [unit time | number of operations | number of service requests] whereby Injury and illness severity may be measured in terms of hospitalizations or days of work lost.
  • [Replacement cost | repair cost | initial cost] of [data | hardware | software | facilities | third party] property damage [caused | permitted | N/A] per [unit time | number of operations | number of service requests]
• Safety Incidents:
  • [Existance | number | average number] of [safety incidents | accidents (of a specific type and severity) | near accidents (of a specific severity)] [caused | permitted | N/A] per [unit time | number of operations | number of service requests]
• Hazards:
  • [Existance | number | average number] of [one or more simultaneous] [hazards (of a specific type)] [caused | permitted | N/A] per [unit time | number of operations | number of service requests]
• Safety Risks:
  • [Amount | level] of safety risk [total | of a specific type] [caused | permitted | N/A] [per [unit time | number of operations | number of service requests] | N/A]
• Safety Incident Detection.
  • [Existance | percentage | number] of [safety incidents | accidents | near misses | of a specific subtype] [caused | permitted | N/A] [identified | not identified] per [unit time | number of operations | number of service requests]
  • [Existance | percentage | number] of [safety incidents | accidents | near misses | of a specific subtype] [caused | permitted | N/A] [recorded | not recorded] per [unit time | number of operations | number of service requests]
• Safety Incident Reaction.
  • [Percentage | Number] of [safety incidents | accidents | near misses | of a specific subtype] [caused | permitted | N/A] [analyzed | not analyzed] per [unit time | number of operations | number of service requests]
  • [Percentage | Number] of [safety incidents | accidents | near misses | of a specific subtype] [caused | permitted | N/A] [reported | not reported] per [unit time | number of operations | number of service requests]
  • [Percentage of the time | number of times] that a [specific service] is [caused | permitted | N/A] to [degrade | not degrade] per occurrence of a [safety incident | accident | near miss | of a specific subtype]
  • [Percentage of the time | number of times] that a [specific degraded service] is [caused | permitted | N/A] to [be restored | not be restored] [within time limit] per occurrence of a [safety incident | accident | near miss | of a specific subtype]

Mechanisms

Typical mechanisms for achieving safety include:

• Hardware redundancy or backups (e.g., multiple sensors or actuators performing the same function)
• Functionality implemented in both hardware and software
• Data consistency monitoring.
• Use of heartbeat to identify dead or frozen processes
• Avoidance of concurrency failures including race conditions, deadlock, and starvation
• Multiple methods for user input and output (e.g., hardware button/switch and touch screen button)
• Confirmation of safety-critical user input
• Built-in hardware device failure detection sensors

Guidelines

The following guidelines have been found to be useful with regard to safety:

• Because nothing is ever 100% safe, a major safety goal is to achieve an acceptable level of safety. Thus, the typical objectives of safety are to:
  • Eliminate accidents or mitigate their negative consequences.
  • Eliminate or mitigate hazards
  • Ensure that safety risks are acceptably low
• A safety-critical application is one that is capable of causing harm if it fails.
• Safety is restricted to unintentional harm. Weapon systems should naturally cause intentional harm to or loss of the enemy’s life or property, while implementing safety for its users.
• Safety is a system-level attribute that may be implemented by data, software, hardware, or some combination of the three.
• By using the concept of ‘adequate safety’, safety can be improved by decreasing either the safety impact occur.
• Safety may depend on the context in which the application is used. For example, the failure of a microprocessor-controlled drug infusion pump is much more critical when infusing a drug into a critically-ill patient than when infusing a relatively nontoxic drug into a laboratory animal during an experiment.