Historically some car makers have used internal, proprietary software safety guidelines as their way of attempting to assure an appropriate level of safety (Koopman 2018b). If a safety argument is based in part upon conformance to a safety standard, it is essential that the comprehensiveness of the safety standard itself be supported by evidence. For public standards that argument can involve group consensus by experts, public scrutiny, assessments of historical effectiveness, improvement in response to loss events, and general industry acceptance.
On the other hand, proprietary standards lack at least public scrutiny, and often lack other aspects such as general industry acceptance as well as falling short of accepted practices in technically substantive ways. One potential approach to argue that a proprietary safety standard is adequate is to map it to a publicly available standard, although there might be other viable argumentation approaches.
Sometimes arguing compliance with a well-known and documented industry safety standard may be inadequate for a particular safety case. Although all passenger vehicle subsystems in the United States must comply with the Federal Motor Vehicle Safety Standards (FMVSS) issued by the National Highway Transportation Safety Administration (NHTSA), compliance with these standards alone concentrates on mechanical and electrical issues, and only high level electronics functionality. FMVSS compliance is insufficient for a safety case that must encompass software (Koopman 2018b).
Similarly, use of particular standards might be an accepted or recommended practice, but not a means of ensuring safety. For example, the use of AUTOSAR (Autosar.org 2018) and Model Based Design techniques are sometimes proposed as indicators of safe software, but use of these technologies has essentially no predictive power with respect to system safety.
For automotive systems with safety-critical software, ISO 26262 is typically an appropriate standard, although other standards such as IEC 61508 (IEC 1998) can be relevant as well. For some autonomous system functions, conformance to ISO PAS 21448 (ISO 2018) might well be appropriate. A new standard, UL 4600, is specifically intended to cover autonomous vehicles and is expected to be introduced in 2019.
Arguments of the form "technology X, standard Y, or methodology Z is adequate because it has historically produced safe systems in that past" should address the potential issues with "proven in use" argumentation considered in the following section.
(This is an excerpt of our SSS 2019 paper: Koopman, P., Kane, A. & Black, J., "Credible Autonomy Safety Argumentation," Safety-Critical Systems Symposium, Bristol UK, Feb. 2019. Read the full text here)
- Autosar.org (2018) The Standard Software Framework for Intelligent Mobility, https://www.autosar.org/ accessed Nov. 5, 2018.
- Koopman, P. (2018b), "Practical Experience Report: Automotive Safety Practices vs. Accepted Principles," SAFECOMP, Sept. 2018.
- IEC (1998) IEC 61508: Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems, International Electronic Commission, December, 1998.
- ISO (2018) Road vehicles – Safety of the Intended Function, ISO/PRF PAS 21448 (under development), International Standards Organization, 2018.
Good post, Dr. Phil. Software is, however, only one component of many that are needed to implement a safe transportation system.
ReplyDeleteIMHO, it is not even the most important. The most important is to create an organization that is transparently committed to produce safe products and systems, and that structures itself and operates in such a way as to teach, reinforce, and sustain that commitment through all organizational levels. Any organization's reputation as a trustworthy and honest business partner is hard to earn and easy to lose, and this goes double for those who make claims for the functional safety of their products and systems.
Having said this, no organization will be perfect enough, or have employees brilliant enough, to produce 100% safe products. The organization, therefore, must also devise a well-defined process for managing situations in which its products and/or systems are involved in mishaps. This is to ensure that each mishap is properly investigated, that the root cause of the incident is determined, and that corrective action is taken to remedy the lapse in safety. At the same time, the organization must honestly communicate its progress towards a resolution with those affected by the mishap.
For makers of autonomous automobiles, such a mishap may result in serious property damage or destruction, and loss of multiple lives. It is not a business for the faint of heart.
If the organization is successful in inculcating a deep safety culture among its own employees, then questions about choices such as appropriate software safety standards will more likely be made with the thoughtfulness and seriousness that they deserve by people who are invested in finding the best answer.
I completely agree that a strong safety culture is essential. Picking the wrong safety standard, using a weak standard, cutting corners, etc. are all signs of a weak safety culture.
Delete