IEC 61508, the original

The following ISO and IEC set of development standards:

  ISO 26262 (Automotive)
  IEC 61508 (Industrial)
  IEC 62304 (Medical devices)
  EN 50128 (Railways)
  IEC 60880 (Nuclear energy)

61508 is the safety-critical parent of 26262.

From the Muse:
Often we don't know a lot about the hunk of code we'd like to incorporate, leading to the somewhat onomatopoeic acronym SOUP: SOftware of Unknown Pedigree.

IEC 61508 is probably the most well-known standard for building safe systems. A portion of that document covers software. It identifies four Safety Integrity Levels (SIL) from 1 to 4, with SIL4 representing a system whose failure would be catastrophic. So, can SOUP be used in a system qualified to 61508? The answer is, "it depends."

There are three routes to gaining certification for SOUP under 61508:

The software was created under the auspices of the standard.
The software has been "proven in use" over time.
Noncompliant software is ex post facto assessed at the desired SIL level.

That leaves option 2. To meet this requirement the integrator of the component (not a component's vendor) must demonstrate that it has been used in a similar role for a certain number of hours. Its uses and failures, if any, need to be recorded. Further, it must have "a restricted and specified functionality," which would seem to leave out big packages like desktop operating systems.

The standard defines two kinds of systems. One that supports "low demand mode of operation" is generally turned off or is usually not performing any safety functions. A trivial example is a TV remote control that only comes to life when a button is pressed. Then there are "high demand or continuous mode of operation" devices: basically, those that run a safety function all of the time. An example might be a nuclear power plant controller, or, in some families, the TV set (assuming the TV is considered family-critical!).

The standard's reliability requirements are:

Formulas are provided to turn those figures into number of requests ("treated demands") or hours of operation to show a component is proven-in-use. Assuming 99% and 95% confidence levels, these work out to:

Autonomous Driving Terms (from SAE)

OEDR = object and event detection and response
DDT = dynamic driving task (all aspects of driving tactically, but none of the strategic functions like route selection and timing)
ADS = automated driving system, specific to levels 3-5; contrast with the generic non-acronym “driving automation system” that can be any level system or feature
ADS-DV = a level 4/5 vehicle designed to be driverless, might not have human control interfaces but might be operated temporarily by conventional or remote driver
DDT fallback = response by the user after DDT failure condition
ODD = operational design domain

Active safety systems like ABS, stability control, etc are NOT “driving automation”.

Level 0 – driver performs all DDT with/without active safety systems (any ODD)
Level 1 – “Driver Assistance” - a driving automation system handles lat or long motion control only
Level 2 – “Partial Automation” – a system handles both lat/long subtasks while driver supervises
Level 3 – “Conditional Automation” – ADS performs entire DDT with fallback-ready user for any failure
Level 4 – “High Automation” – ADS performs entire DDT including fallback with no user expectations
Level 5 – “Full Automation” – ADS performs entire DDT including fallback with no user expectations (any ODD)

Levels 1 – 4 are “ODD-specific”.
Levels 4-5 mean NO driver, only a passenger.
Levels are assigned, rather than measured, and reflect the design intent for the driving automation system feature as defined by its manufacturer. Therefore a feature is NOT non-compliant or unsafe against the SAE definition document.

It is incorrect to describe driving automation features using fractional SAE J3016 levels, such as 2.5 or 4.7

It is not logically possible for a given feature to be assigned more than a single level. The feature is either capable of the advanced level or not. But it is possible to deliver a feature at different levels in different usage specifications.

ASIL and 26262

References
https://www.synopsys.com/automotive/what-is-asil.html
http://sesamo-project.eu/sites/default/files/downloads/publications/iso-26262-dis-tutorial-2010-final.pdf

This spec applies to vehicles of 4+ wheels only. Focused on safety goals and provides requirements to achieve an acceptable level of risk.

For each hazardous scenario, evaluate Severity | Exposure | Controllability
Then, use the result to set ASIL.

SYSTEM

System Level Product Development Work Products

Overall project plan (refined)
Safety plan (refined)
Validation plan
Functional safety assessment plan
Technical safety requirements specification
System level verification report
Technical safety concept
System design specification
Item integration and testing plan
Requirements for production, operation, service, and decommissioning
HW/SW interface specification (HSI)
Integration testing specification
Integration testing report
Validation report
Functional safety assessment report
Release for production report

HARDWARE

Probabilistic Method for Random Hardware Failure
Compute probability of violation of each safety goal due to random hardware failures and then compare it to a target value in the table showing each ASIL level.

Residual Risk Evaluation Method
Individually evaluate each single point fault, residual fault and dual point failure of the hardware parts which violate the considered safety goal.

SOFTWARE

Requirements flow down chart from the top:

Hazard analysis and risk assessment
Specification of safety goals
Specification of functional safety requirements
Specification of technical safety requirements
System design specification
Hardware and Software safety requirements

Design flow from top down:

Create spec of SW safety requirements
SW architectural design
SW unit design and implementation
SW unit testing
SW integration testing
Verification of SW safety requirements