Can Phil explain how a “safety case” relates to the requirements and clauses in UL 4600? It is not clear if a safety case is posted independent of the requirements and clauses, or for the expressed purpose of validating requirements and clauses included in UL 4600.
The clauses in UL 4600 describe the properties of an acceptable safety case. This includes minimum content (e.g., specific hazards to consider), structural properties (e.g., traceability), and use of field engineering data monitoring to address epistemic uncertainty. Section 17 addresses how the assessment is performed, and may therefore, in some cases, go beyond what is strictly in the safety case. This a larger view of “safety case” than is often found, and makes the safety case an overarching structure rather than one work product among many.
Change impact analysis: To what level of granularity would configuration management/control needed/required?
UL 4600 allows developers to pick a granularity they find useful. There is likely to be a tradeoff with granularity in terms of book-keeping overhead vs. chunk size of revisiting self-audit and independent assessment. However, each time a product instance (a particular vehicle) is updated, there must be an identified safety case that is valid for that specific vehicle’s configuration. (Parameterization and use of calibration data is fine, but the safety case has to apply.)
Do you envisage the standard will be applicable to non automotive use cases such as last mile delivery autonomous robots?
In principle, yes, especially for wheeled vehicles. Section 1.6 discusses how to do this. The UL 4600 roadmap plan is to address other autonomous product types more directly in the future.
Do you distinguish between “acceptability” and sufficiency of the evidence relative to the state-of-the-art, organized in a reasoning structure?
This version of the draft gives the developers leeway to do the right thing in exchange for them having to take responsibility for owning safety. Acceptable is defined in paragraph 4.2.1 as “Sufficient to achieve the overall item risk as determined in the safety case.” Overall item risk is covered in paragraph 6.5.1.
Do you foresee that this standard becomes soft law?
We see this as a tool for industry to use in being responsible providers of systems that society considers to be appropriately safe.
Does UL 4600 identify criteria to determine independence?
Section 17.3.3 covers the assessment report, paired with evidence of assessor capability. The argument for both independence and capability of the independent assessor are included in the assessment report itself. As with many aspects of UL 4600, transparency is favored over prescriptive decision criteria. Thus, there is flexibility in determining reasonable independence. Weak independence claims should be apparent to readers of an assessment report.
Even in a “fully” autonomous vehicle, shouldn’t there be a provision for exiting the autonomous mode safely? Could that not allow for “safe hand-off to a human”?
UL 4600 does not preclude handoffs. Section 7.7 covers the safety of mode changes that invoke human safety responsibility, including hand-offs. However, UL 4600 does not attempt to provide specific support regarding human ability to accept and operate a vehicle after handoff. As a specific example, if you think 10 seconds is enough handoff time, UL 4600 covers actually providing the full 10 seconds. But not whether 10 seconds is in fact going to be enough for the human driver to be safe. Please refer to the examples in Sections 2.3.2 and 2.3.3 for more. Human driver/supervisor interaction with autonomy can and should be a different standard that has an STP with a skillset emphasizing human computer interaction.
FYI: SAE J3016 has good definitions of automated, autonomy, driverless automation, and more relevant definitions
The STP did a study of a number of standards with regard to terminology across multiple domains and standards. UL 4600 attempts to minimize the number of terms defined. Generally it only offers a definition when it is essential to understanding UL 4600 normative material and common technical term meanings did not do the job. If during review you find a substantive terminology conflict, please inform us by submitting a comment in the template in the UL 4600 Proposal Review Work Area in CSDS.
Hello, I note the table in A.4 (mapping to SOTIF) is empty. Can I interpret this that SOTIF does not add anything (at all) provided that ISO 26262 is performed correctly?
This is not the intended interpretation. It says “currently no mapping has been identified between UL 4600 and ISO/PAS 21448:2019.” First, UL 4600 does not attempt any comparison of nor provide any opinion on the comparative suitability of ISO 26262, ISO/PAS 21448 (SOTIF), or other standards. Second, the purpose of these tables is to map clauses of UL 4600 into those two standards where there is significant overlap to help avoid rework. Un-mapped clauses in both ISO 26262 and ISO/PAS 21448 are still likely to provide support for safety cases. It is simply that the clause-to-clause mapping might be less direct than the mappings identified, and are more likely to depend upon the specifics of a particular safety case. Additional proposals for general mappings for the tables included are welcome as comments as informative text.
I have a question: Is UL 4600 intended primarily for road vehicles, or for other vehicles as well? Most of what I see in the draft seems oriented to road vehicles.
Please refer to the answer provided in response to the “last mile delivery autonomous robots” question above.
Is it appropriate to include lists of hazards, both to and from an AV, in the standard or in an appendix to the standard?
The drafters of UL 4600 have elected to include them in the standard. As an example, the FDA has a document for infusion pumps that does this to avoid different companies making the same mistake. “Infusion pumps total product life cycle” Dec 2, 2014.
(https://bit.ly/2VC2eIk Thanks to Kim Wasson for identifying this document.) Many of the hazards in UL 4600 are generic hazard categories rather than ultra-specific hazards, with specific hazards being offered as non-normative examples.
Is not yet fully clear how the standard is positioned with respect to ISO 26262 and ISO 21448. Do you plan to have any guidance about how to reuse work products from those standards? And is your position that an automated car can be safe even if it does not comply with ISO 26262?
Use of This Standard with Other Standards, Section 1.5, of UL 4600 discusses this topic specifically, with support from Annex A (Use with ISO 26262 and ISO/PAS 21448). In principle, an automated car might be safe if it conforms to an alternate safety standard, such as IEC 61508 or MIL-STD-882, especially if the ODD for MIL-STD-882 is something like military convoy operations. UL 4600 is agnostic on this point.
It seemed you used the term “supply chain” in the sense of “dependency chain/path” in common usage refers to a chain of suppliers.
The term supply chain is used in the normal sense. However, that supply chain does create a dependency in that the system level safety case has to assume (or show) that properties of supplied components and materials match up with what is required by the safety case. Without a human driver to serve as a flexible, general purpose risk mitigation agent, supply chain issues seem likely to require increased attention. Section 14.5 specifically addresses this topic.
On exiting ODD: Is the system required to recognize when it is exiting the ODD or more specifically approaching the limit at which it cannot reach a safe state?
The requirement is “8.2.3 ODD violations shall be handled in an acceptably safe manner.” This includes detecting whether or not the item is inside or outside of the ODD and mitigating risk while transitioning out of the ODD. Being proactive when approaching the limit of the ODD is likely to be helpful. However, the safety case has to address the possibility of the vehicle being forcibly ejected from its ODD (for example, by unusual un-forecast weather, or roadway infrastructure faults). That doesn’t mean the system has to keep operating, but rather that one way or another the safety case has to argue the system level risk is still acceptable despite the possibility of exiting the ODD. The particular strategies used are up to the developer.
Q1. How do we ensure true independence for audit and assessment of Safety case of OEM’s and Suppliers. Do we expect equivalent of FAA approved Design Engineering Resource to be introduced in Automotive?
Please refer to the answer provided in response to “independence” above.
Q2: Should human factors of other road users and how they interact with subject Autonomous vehicles not be considered?
Interactions with Humans and Road Users, Section 7, covers human factors of non-drivers. The difference between drivers and non-drivers is important due to the assumption that drivers serve as a general-purpose risk mitigation agent in traditional vehicles that will not be present in fully autonomous vehicles. Risk mitigation credit taken for non-drivers must be justified. (“Drivers” also includes “safety supervisors” whether remote or in-vehicle.)
Re: the black swan problem, can it be dealt with by defining the ODD to identify the boundary of what is known?
The problem with inductive arguments in this case is that you are making assumptions in defining the ODD boundary that might not be true. As a hypothetical example, you define an ODD boundary to include recognizing and avoiding swans because you drive through a park with ponds regularly. However, all your training data is white swans. When an imported black swan shows up in the park you might not recognize it as a bird to avoid hitting, and you hit a swan despite having “proven” previously you will never hit a swan. In this example you have violated your de facto ODD due to a literal black swan causing an unknown unknown difference between your de facto ODD and your intended ODD.
Several statements in the draft, will they include reference to paper or other evidence before publication?
We are still working on references, but it is not likely that hundreds of references will be cited without specific suggestions. Please include any specific statements you identify as requiring a reference (including suggested references if possible), please include these in your comments and post in the template provided in the UL 4600 Proposal Review Work Area in CSDS.
What is the intended meaning of “rigor”?
Generally Merriam-Webster (4): “strict precision”. “Level of Rigor (LoR)” is a phrase from MIL-STD-882. (A word search shows it is used 34 times.) Please feel free to provide suggested wording for specific instances should you have concerns about ambiguity in the use of the word. Please put your comments in the template provided in the UL 4600 Proposal Review Work Area in CSDS.
What is the position of the standard with respect to COTS? Can they be used under certain conditions/arguments?
Yes, but not blindly. Tool Qualification, COTS, and Legacy Components, Section 13, in general addresses this topic. Section 13.4 addresses COTS and legacy components. Section 5.3.3 includes argumentation pitfalls commonly encountered in dealing with COTS components.
Why is security (partially) outside the scope of the standard?
Security is mostly outside the scope of the standard for at least two reasons: (1) to avoid overlap with other active standardization efforts, and (2) because addressing that topic robustly would require a Standards Technical Panel (STP) with a much stronger security skillset.
Why UL 4600 type for non-autonomous vehicles?
Aspects of UL 4600 might apply to non-autonomous vehicles, but the standard has not been specifically designed for that purpose.