UL 4600 Tech Q&A

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.

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.)

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.)

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.

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.

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.

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.