2019年7月2日，白皮书《自动驾驶安全第一》发布，这本白皮书由11家自动驾驶相关的企业联合编著而成。（添加微信：NewCarRen，回复【自动驾驶安全第一】，即可下载白皮书中文版。）今天，笔者将结合这本不属于任何组织或者研究机构的白皮书，来阐述我对自动驾驶汽车安全的看法。
上一篇，我们简单总结了与汽车安全相关的几个标准，这一篇，我将总结156页的《自动驾驶安全第一》白皮书，并阐述自己的一些看法，如果你也阅读过这本白皮书，不妨在文章下方留言，我们一起来讨论吧！
白皮书《自动驾驶安全第一》于2019年7月2日公开发表。
在SOTIF中，标准只覆盖到了L2，另外如前篇（关于自动驾驶汽车安全的思考：汽车安全相关的标准（上））所述，SOTIF只提供了框架，《自动驾驶安全第一》白皮书中具体提出了实现L3及L4的方法。
在第1章《引言及动机（Introduction & Motivation）》中，添加了适用范围sec. 1.1）和文书结构（sec. 1.2）之外，还展示了关于自动驾驶的以下12条原则（the Twelve Principles）（sec. 1.3.2、表2）。在白皮书《自动驾驶安全第一》中，各原则没有加上编号，为了方便使用，我们在此附上编号。
《自动驾驶安全第一》 Principles 原则 (sec. 1.3.2)
1. Safe Operation | 1a. Dealing with Degradation | 如果与安全相关的功能或系统组件陷入危险状态（例如，故障），则自动驾驶系统（ADS）会切换到安全状态/状态，同时保持系统的平衡状态，另外，将控制权转移到驾驶员手中，确保有足够的时间长度以实现安全的控制转移。 |
1b. Fail-Operational(limited to the safety-related function or component) | 与安全相关的功能及系统组件的缺失，不会导致安全相关的事件发生。 | |
2. Operational Design Domain | 2a. ODD Determination | 一旦发现系统到达了限制ADS功能安全的系统极限时，系统必须及时响应以保持平衡，或者给予充足的时间范围要求驾驶员进行驾驶模式转换。 |
2b. Manage Typical Situations | 在ODD中充分考虑一般预想的情况，应对可能发生的风险。 | |
3. Vehicle Operator-Initiated Handover | ADS的启动和解除中，关于驾驶员的意图，需要给予有较高确信程度的明确指示。 | |
4. Security | 提供ADS的情况时，必须采取措施保护ADS免受安全上的威胁。 | |
5. User Responsibility | 为了提高安全性能，用户需要负起责任，保持完全应对状态（也就是警戒状态）。系统会不断通知使用者认识到用户的状态以及使用者必须做到的责任。另外，需要通知每位驾驶员关于无人驾驶服务中安全相关的驾驶状态。 | |
5a. Responsibility | 驾驶任务中，作为用户责任遗留的部分对于用户必须明确。 | |
5b. Mode Awareness | 在自动化功能中，必须明确且无误地认识到现在活动行驶模式。另外，用户也必须明确驾驶模式的变换。 | |
6. Vehicle-Initiated Handover | 6a. Minimal Risk Condition | 车辆驾驶者如果不符合接管车辆要求，ADS必须执行将风险最小化的车辆操作，以达到最小风险状态。此操作根据情况和ADS当下的性能。 |
6b. Takeover Requests | 驾驶员必须明确理解和管理车辆接管事宜。 | |
7. Interdependency Between the Vehicle Operator and the ADs | 为了综合评价系统的安全性，自动驾驶期间结束之后以及行程中自动驾驶部分开始时，需要考虑自动化带给驾驶者的影响。 | |
8. Safety Assessment | 验证和稳妥性确认为了达到整体安全性一贯的改善程度，为了切实达到安全目标而使用。 | |
9. Data Recording | 自动驾驶车辆根据适用的数据政策关联法，认识到突发事件和偶发事件时，必须记录ADS状态相关的数据。 | |
10. Passive Safety | 10a. Crash Senarios | 车辆设计必须对应车辆自动化带来的冲突情景的变换。 |
10b. Alternative Seating Positions | 由于ADS，在新的可使用的车仓的用途中，也必须要保护成员安全 | |
11. Behavior in Traffic | 11a. Manners on the Road | 自动化功能的行为对于周围（包括交通弱者）的道路使用者来说，必须易懂，在可预测范围内易于管理。 |
11b. Conforming to rules | 适用的交通规则必须根据自动驾驶系统加以考量。另外，上述原则5. User Responsibility需要说明使用者的责任。 | |
12. Safe Layer | ADS必须认识系统的局限，特别是对于驾驶员不能安全控制的界线，将风险最小化。 | |
除了最后的「12. Safe Layer」，以上都是简单易懂的内容。仅凭Safe Layer两个单词，很难读取其中的内容，但是如果能继续往下读条文，意图就会十分明确。可能最初确实有某个子项目，由于被删除了就变得难以理解了。（若以这种推理读解的话，就会发现很多难以发现的地方，这就是最后的项目，可能只能理解为“回收站”吧！把不要都项目都归类到这里了…）
另外，国土交通省于2018年9月12日发表了《自动驾驶车辆安全技术指南》，建议L3和L4的自动驾驶车辆应该要满足的安全相关的要求，以上原则其中有10个项目是和指南相重合。例如，原则11a，虽然没有重复，但是像7、8、10那样，解释的更加具体。
《自动驾驶安全第一》――第二章
《自动驾驶安全第一》的第2章“系统地开发可靠性以支持通过设计实现安全”，要求自动驾驶具有失效安全能力（FS）和失效降级能力（FD）（表3中分别显示了FS_1至FS_7和FD_1至FD_6，第2.1和2.2.1节），为此，展示了实现这些功能的特定元素（第2.2.2节），以及 ，显示了其一般逻辑体系结构的整体图（图26中的2.3节）。
ID | Capability | |
FS_1 | Determine location | 确定位置 |
FS_2 | Perceive relevant static and dynamic objects in proximity to the automated vehicle | 感知相关的静态以及动态物体 |
FS_3 | Predict the future behavior of relevant objects | 预测相关对象的未来行为 |
FS_4 | Create a collision-free and lawful driving plan | 制订无碰撞且合法的驾驶规则 |
FS_5 | Correctly execute and actuate the driving plan | 正确执行驾驶规划 |
FS_6 | Communicate and interact with other (vulnerable) road users | 与其他的道路使用者（包括交通弱者）交流和互动 |
FS_7 | Determine if specified nominal performance is not achieved | 确定是否达到特定标称性能 |
FD_1 | Ensure controllability for the vehicle operator | 确保车辆运行者的可控性 |
FD_2 | Detect when degraded performance is not available | 检验降级模式是否可用 |
FD_3 | Ensure safe mode transitions and awareness | 保障安全模式的转换和正确状况的把握 |
FD_4 | React to insufficient nominal performance and other failures via degradation | 应对故障降级引起的公开性能不足等情况 |
FD_5 | Reduce system performance in the presence of failure for the degraded mode | 在失效时降低系统性能 |
FD_6 | Perform degraded mode within reduced system constraints | 减少系统限制范围内，故障降级模式的执行 |
描述达成安全性能的论证想法和推进方法确实不容易，通过给予获得这些能力的论证、实际安装的框架要素以及整体构成等架构，使论证的想法和推进方法制定变得更加轻松，同时以此框架为根基，构建各种各样的支持框架（基石和论证的自动化支援）就比较容易了。
《自动驾驶安全第一》――第三章和第四章
第3章是验证及确认（Verification and Validation, V&V）。
在Sec. 3.1中，与非安全及达到SAE L2的过去的V&V方法并行运行，作为SOTIF特有的V&V步骤，如图2“功能设计的反复流程”所示。
通过此反复流程，推进对已知非安全场景的应对，提高安全性。当然，不可能完全做到零风险。如下为英文说明。
100 % reliability of the system and 100 % confidence in a given level of reliability are not possible due to the complexity and time variance of the system and the corresponding uncertainties. Thus, there will remain some small risk of crashes. The concept of residual risk has already been accepted for a long time now (see the rollout of airbags or new medicines).
翻译成中文：“由于系统的复杂性、时间的变化以及伴随而来的不确定性，不可能有100%的信任度和对特定信任度100%的确信度，因此冲突风险多多少少都有所存在。残留风险的思考方式（正如安全气囊和新药投入市场一样）已经长期被人们接受”。在这里正如特意写的那样，有存留风险，以及虽有风险，但可以接受，这一点已经成为前提。
在Sec. 3.2中，L3和L4系统所面临的V&V主要挑战（Key Challenges for V&V of L3 and L4 Systems），展示了表4的5个项目。
No. | Challenges | |
1 | Statistical demonstration of system safety and a positive risk balance without driver interaction | 无驾驶员干涉下，关于系统安全性和正风险平衡的统计论证 |
2 | System safety with driver interaction (especially in takeover maneuvers) | 驾驶员接入时的系统安全（特别是接管操作中） |
3 | Consideration of scenarios currently not known in traffic | 在交通中，当前未知的场景研究 |
4 | Validation of various system configurations and variants | 关于各种系统配置和变量的确认 |
5 | Validation of (sub) systems that are based on machine learning | 对基于极其学习的（子）系统的确认 |
另外，sec. 3.6中，按照每个要素的V&V进行论述。例如，关于电源，应该要冗余，对L0~L2系统，根据每个电源系统进行测试，但是在L3以上，关于电源切换动作，需要追加测试，这一节中也展示了具体的方式方法。
在Sec. 3.7中，关于现场运行（Field Operation）也进行了相应的说明。
在第4章提到，将以此白皮书的内容为基础，添加V&V流程和详细信息，进行ISO的转换。正准备发行的「ISO/TR 4804 Road vehicles - Safety and cybersecurity for automated driving systems - Design, verification and validation methods」（ISO/TR：Technical Report（技术报告、TR）。与提供各种规定（provision）的IS不同，以提供各种“数据”为目的。）就相当于此，截至2020年7月23日，该草案已达到CD的最终阶段（Stage Code 30.99 CD approved for registration as DIS），可以预测，不久可能发行DIS（ISO DTR 4804）。
ISO/SAE 21434的DIS虽然在发行后不久可以购买，但DTR的情况下，是否可以买入不确定。很遗憾，并没有发现是否可以买入设计草案的正式规定，但入手还是可以值得期待的。
从白皮书中的想法看出的平台与标准规格的结合方法
确定了像AUTOSAR Classic Platform（CP）的Application Interface（AI）那样关于非竞争领域的「Application」标准架构，并且如果其充分普及的话，就能够采用更加具体且有效的方法。但是根据现状（R19-11）中的CP，Application Interface并没有普及开来，本来根据AUTOSAR AP，也并没有Application Interface定义本身。
但是，关于理论框架和物理框架，即使AUTOSAR以外，关于各种各样框架阶层，也可以进行假设（需要进一步推进，进行设计标准化）。今后，若增加此类措施和方法的话，在所谓的平台程度上，也能够增加可覆盖的各种机制。例如，从JASPAR的AD/ADAS车辆控制IF WG看来，在2020年3月13日JASPAR的Web网站上公布的「AD/ADAS车辆控制界面使用书Ver.1.0（ST-AVI-1）」这样的措施方法可以发挥“基础”作用。
但同时，并非只做“假设”，只进行选择就行。
一般说来，用于系统实现的体系结构设计（=指定实现上位要素的框架要素群和I/F，对各要素，去除故障要素的活动）有各种各样的选择。另外，关于更多的元体系结构层次模型也是一样的。
更多的元体系结构层次模型：例如，从整个行动系统到单体软件若出现故障的话，可以考虑如下的阶层结构（这是一个案例，实际上可以间隔使用）。
・整个行动系统
・行动系统的“登场人物/要素”（例如：汽车和基础设施、使用交通人员）
・汽车的系统领域
・汽车的ECU
・ECU内的子系统（例如：处理器）
・处理器内的（Virtual） Machine（（假想）硬件和软件的集合体）
・软件内的集成
・软件的模型（例如：AUTOSAR CP下的SW-C和BSW）
・软件的模型内组成要素
另外，关于最后的“软件模式内组成要素”，例如在RTOS和CRC程序库参数中，到单体软件故障的必要性和确切组成有很大差异（根据最终的接近“末端”的模式种类）。因此，制定千篇一律的基准十分困难，但是具化最终的“末端”，可以进行程度的定义。
在这些更多的元体系结构层次模型和实际框架结构的“假设”基础上，构建“具体”的设计资产。推进假设，使构建的设计模型标准化并共享，通过此增加整个业界的共同资产。
但是，如前所述，在框架中也有很多选择选项。使用的此种“假设”如果能够成为社会上的主流就好了，但是如果成为支流的话，可使用的设计资产就会相对减少，很可能被并非state-of-the-art的东西（过时的东西）随波逐流。“具体的”“可具象化的”十分重要，但是在标准化活动的战场中，如果没有同时站在“较高的抽象度”上的话，就会将没有前景的黯淡的或者被明示的“假设”作为多数派加以维持，或者追随其后。
很多情况下，我们容易将“抽象化的东西”评价为“没有具体性”，但是我觉得如此轻视决定的东西稍微有点浪费。关于“掌握”这类部分的必要性，每次看到这种不在意的样子时，都会稍微有点担心，这也是事实。
