我们开篇首先聊聊自动驾驶的安全困局，以及预期功能安全(SOTIF)基本问题。随着汽车电子电气系统不断复杂化，安全问题近些年越来越受到行业内的重视，尤其对于自动驾驶系统而言，虽然汽车行业内很多车企，供应商都为此投入大量的开发资源和庞大的资金支持，但自动驾驶，尤其是高级别自动驾驶系统和资本的预期相差甚远，SOP一推再推，久久不能落地，甚至目前行业内还有很多关于自动驾驶本身无解的悲观言论，毋容置疑，其中安全问题就是阻碍其最终落地的重要影响因素之一。那自动驾驶系统安全问题到底有什么特殊性呢？存在哪些困局呢？那对于自动驾驶系统而言，其安全问题的特殊性在于技术，但又不仅仅局限于技术难题，个人理解: 和传统的电控系统（例如，传动，底盘，转向等）相比，自动驾驶系统本身以及和其它系统交互的复杂性不言而喻。为此，基于确定或者白盒化的模型（简单的说，就是能通过物理公式对其进行建模）的传统汽车开发思路和手段已经完全不再能够应对自动驾驶系统的复杂性带来的挑战，为此，大量的机器学习，人工智能等非白盒化模型应用于自动驾驶控制系统，以此代替现有驾驶员的职能。
虽然这些非白盒化算法有效帮助我们实现复杂的系统的功能，并且随着大量数据输入的迭代，算法本身也会进化，变得更加智能，但与此同时，我们也越来越难真正从物理规律的角度去理解这样开发出来的系统，甚至基于数以万计训练参数的机器算法模型，已经基本上超越了人类的理解范畴。
现有安全法规多基于安全分析，而安全分析多基于白盒思维，除对开发流程约束外，主要是对研究对象的结构和实现的功能进行逐层的安全分析，找出安全薄弱环节，然后实施相应的安全措施。在这样的情况下，基于白盒化的安全分析活动的可实施性无疑受到了极大的限制和挑战，工作难度及工作量急剧上升，研发人员的可靠性决定了安全开发的可靠性，安全分析的作用被迫降低，只能通过大量的基于不同场景的仿真和长期的测试验证和确认尽可能保证自动驾驶系统的安全性，其最终效果如何，也不得而知！
为了实现汽车自动驾驶的功能，尽管自动驾驶系统采用了大量的感知传感器，图像及视觉处理识别技术，规划算法等，但在复杂的驾驶环境中，这些技术仍然存在很多限制性。例如，识别车辆所处的运行环境，包括交通标识（可能不完整或被遮挡），交通规则，其他交通参与者，没有被机器学习算法覆盖的不明障碍物等。这些情况都需要自动驾驶系统快速准确地识别和判断，并做出正确的驾驶决策。
例如，雨雪天气，道路坑洼和泥泞，道路维修等。这些情况可能会影响传感器的性能和对其判断，进而导致自动驾驶系统无法准确地感知周围环境。
所以，人们发现自动驾驶车辆安全问题并非都源于功能安全问题（即由系统性失效和硬件随机失效带来的安全问题）。在复杂的运行场景中，自动驾驶系统即便没有功能安全相关的失效，但由于当前技术的制约，包括传感器，算法等本身性能的局限和不足，依然会产生很多的新非预期的安全问题。当然，为了解决上述的技术困局，我们需要采用更先进的传感器技术和规划算法，同时加强系统的质量把控，但是技术制约的问题依旧存在，且短期不可能得到根本性解决，资本的压力增加，那这样的技术困局如何解决?
在这样的背景下，预期功能安全随之诞生，它主要用来解决自动驾驶系统由于预期性能的不足和合理的人为误用导致的安全问题。
当然，对于自动驾驶系统，功能安全（Functional Safety）和信息安全（Security）问题同样不容忽视，只是和预期功能安全相比，相对比较容易解决。当自动驾驶车辆出现交通事故时，应该如何进行责任认定，哪些属于自动驾驶应有的责任，例如发生交通事故或行人被撞时，谁应该为此负责？是车企、车主还是开发人员？如何进行赔偿？目前关于高级别自动驾驶系统事故责任划分法规基本空白，各车企自动驾驶产品能力层次不齐，大多数车企都不愿意，也没有足够的能力承担相应的责任。在众多利益的博弈下，往往最后受伤的都是最普通的用户，这些问题一方面需要等待自动驾驶技术进一步成熟，同时也需要从法律法规层面研究和探讨，制定完善的法律和法规应对这些问题。1.3 道德困局
除技术，责任的困局外，道德困局也不容轻视。
自动驾驶汽车在遇到紧急情况时，例如，行人突然跳出来，或者老人和年轻人同时处于危险之中，自动驾驶系统应该以什么样的道德标准采取措施？系统是否应该优先保护车上的乘客，还是采取最小伤害原则，不同的企业是否能够采用一套标准，这个标准由谁制定等，这是一个涉及道德和法律问题的复杂问题。
自动驾驶系统需要采用大量的传感器和摄像头感知周围环境，但同时也会收集大量有关驾驶员，乘客以及其他交通参与者的个人信息。这些信息如何处理和保护，由谁监管，如何监管，以避免滥用和侵犯隐私权，这一定程度上也属于道德问题。
虽然目前国内有一些数据安全采集的法规，但多基于国家安全层面出发，也不能保证自动驾驶系统数据隐私安全性问题。
当然，除了以上主要的困局，还有大众对自动驾驶系统的接受度问题，成本问题，人机交互问题等。例如，由于自动驾驶系统人机交互界面不够清晰、易懂，导致人类难以理解车辆的决策过程和风险提示，也可能会造成行车事故。这些都是制约自动驾驶技术落地的重要因素。
技术困局只能依靠技术解决，那么责任和道德困局有没有什么解决办法呢？这个问题很难回答，我只能简单回答如下:
业界应该广泛征求意见，专门针对自动驾驶系统事故责任及道德问题，制定相应的法规和道德协议，明确自动驾驶系统的责任划分，以及在特定情况下的行为准则，道德价值判断标准，将基本道德要求法规化，并将其考虑到自动驾驶系统算法之中，这可以帮助减少自动驾驶系统上路的不确定性和道德问题的出现。例如，在紧急情况下，系统应该优先考虑人的生命安全，而非车辆或财产损失。政府或第三方机构可以设立监管机构，监督和评估自动驾驶系统的安全和道德标准。这可以帮助确保自动驾驶系统不会对公众造成不良影响。国际社会及行业可以制定统一的标准，规范自动驾驶系统的安全设计和操作接口，这样可以确保最基本的安全问题。
教育和宣传可以帮助提高公众对自动驾驶系统的理解和信任。人们需要了解自动驾驶系统的原理、工作方式以及安全性，以更好地理解自动驾驶技术，增加对其接受程度。作为汽车技术从业人员，从技术的角度竭尽全力解决技术困局诚然极其重要，也是必经之路，但自动驾驶其它非技术困局也不能忽视，有时候很多问题都不是单靠技术就能解决的，作为一名汽车行业从业人员，精于技术，但却不能只专注于技术。聊完了自动驾驶系统的安全困局，接下来我们回到我们预期功能安全专题系列内容的主题: 预期功能安全，即SOTIF（Safety Of The Intended Functionality）。
2.1 解决的问题
由上一节自动驾驶系统技术困局可知，预期功能安全旨在解决预期功能的不足，而这些功能不足是由系统本身（包括硬件和软件）性能的不足导致的。
此外，可合理预见的人员误用也会导致危害的产生。例如，驾驶员对自动驾驶系统能力和限制的理解误用了相应的系统，或者驾驶员没有正确理解和应对系统警告，都会直接导致自动驾驶系统的安全问题，这类问题本质是系统本身鲁棒性不够，或者说能力不够，因此也被归到预期功能安全内容。
2.2 预期功能安全标准
预期功能安全作为汽车安全的三大核心内容之一，在行业内也有相应的标准，即ISO 21448: 2022，但和ISO 26262相比，ISO 21448只有一个单独文件，内容相对较少，也属于方法论模型。
从本质上来讲，预期功能安全(SOTIF)和功能安全(Functional Safety)都是在解决汽车电子电气系统的危害问题，二者相辅相成，只不过侧重点或者导致危害的来源不同而已。· 功能安全(Functional Safety):─ 旨在避免因电子电气系统故障而导致的不合理风险，其危害来源于电子电气系统的故障，该故障是由系统性失效和硬件随机失效产生。
─ 适用于汽车各系统的开发，包括高级辅助驾驶及自动驾驶系统。─ 功能安全系统性失效和硬件随机失效基本上都属于已知运行场景下功能安全失效问题。─ 旨在解决由功能不足、或由可合理预见的人员误用所导致的危害和风险，其危害不源于功能失效，而是系统功能不足或合理人为误用。
例如，传感系统在恶劣环境情况下，本身并未发生故障，但不能按照预期执行预期的功能。
─ SOTIF是在自动驾驶技术发展的大背景下提出，是自动驾驶从L2到L3升级的必然需求。随着自动驾驶技术的发展，人们发现车辆安全问题并非都源于系统错误和失效。在复杂的系统以及场景中，问题时常源于外部环境影响带来的非预期性安全问题。─ SOTIF安全开发活动多基于场景(Scenarios)，ISO 21448将将其研究场景划分为如下所图9.16示的4个区间:
Area 1: 已知-安全
Area 2: 已知-不安全
Area 3: 未知-不安全
Area 4: 未知-安全
预期安全活动的目的是尽可能缩小位于区间2和3中的场景的比例，将其转化为1和4的场景，确保场景控制在安全的区间。预期功能安全解决的问题都集中在区间2和3，其中区间3，即未知不安全运行场景下的预期功能安全问题是SOTIF问题的特殊之处且难以解决。
为解决预期功能安全问题，ISO 21448开发流程为此制定了12个关键开发活动，具体如下：
![]()
SOTIF流程始于规范定义和设计(见ISO 21448，第5章)，规范定义和设计中包含了那些在后续SOTIF活动和周期开始前就已知的性能局限和功能不足。这部分内容和功能安全ISO 26262概念阶段中相关项的定义基本类似(具体见第3.2章节），都是对研究对象(对SOTIF而言，为不同级别的自动驾驶系统)的组成(系统及其要素)、功能和性能局限性(例如，分类不足，测量不足，运动学估算不足，假阳/阴性探测等)的充分理解，最终会形成一份已知的功能不足、相关的触发条件及其应对措施(如果已经存在或定义)的详尽列表，以便执行后续阶段的活动。危害分析和风险评估(见ISO 21448，第6章)基本上安全参考ISO 26262中相应内容(具体见第3.3章节)，同样也是根据研究对象整车级别功能安全分析，例如HAZOP，评价危害事件的暴露度(S)、可控度(E)、严重性(C)，只是对SOTIF而言，不会根据S、E、C确定综合的ASIL等级，而是会定义危害事件的接受准则，预期功能安全的接受准则包含两个层面(所谓的双层接受准则)，即：─ 第一层：判断车辆行为是否属于危害行为而可能导致危害事件的准则，即危害行为接受准则；
─ 第二层：针对不满足危害行为接受准则的那些行为，可导致S>0且C>0的危害事件，需要进一步判断车辆运行过程中残余安全风险是否处于合理水平的准则，即残余风险接受准则，并将其作为这一阶段的工作输出结果，在下一个开发阶段进一步确定其触发条件。根据危害分析和风险评估结果，针对不满足危害行为接受准则的那些行为，我们需要识别其触发条件，即分析由哪些原因导致该事件的产生(见ISO 21448，第7章)。针对自动驾驶系统，一般会根据其“感知-规划-执行”模型，对规划算法、传感器和执行器，以及环境条件和合理可预见误用，进行系统性分析，识别和评估潜在规范定义不足、性能局限、输出不足和触发条件。例如，触发条件可以外部环境干扰，道路基础设施，已知规划算法的局限性，感知和执行的精度问题等。触发条件是构成危害事件，进而产生危险的直接诱发因素，也是SOTFI流程中为后续进行系统优化和改进的重要基础。通过潜在功能不足与触发条件的识别，则需要根据已有设计，判断系统是否有相应的安全措施应对这些风险。如果没有的话，那么就需要对系统进行改进与优化(见ISO 21448，第8章)，包括提高性能(更好的传感器技术，算法等)，系统修改(冗余、多样性和互补要素)，功能限制，权限移交等手段，并对规范定义和设计进行更新。旨在制定适当的验证和确认策略(见ISO 21448，第9章)，以提供证据来证明系统：─ 验证：在组件层面，来自已知危害场景的潜在的危害行为得到全面且有效的控制。─ 确认：在整车层面，来自已知和未知危害场景的残余风险满足接受准则并具有足够的置信度。具体而言，就是为后续已知危害场景的评估和未知危害场景(残余风险)的评估，提供相应的策略，包括集成定义，验证和确认活动的导出方法，确认目标定义等。这部分内容和功能安全ISO 26262中第7章节内容，即系统阶段(II)中的验证确认方法基本类似。对于已知场景的评估，包括了对已知场景的验证和确认。对于已知的危害场景的验证部分，根据上一部分内容中的验证和确认策略，只需要对其进行基于场景的验证即可(见ISO 21448，第10章)，同样根据自动驾驶系统决策模型(感知-规划-执行)，分别对其进行感知的验证，规划算法的验证，执行的验证和系统集成的验证，只是根据验证对象的不同其验证方法有所区别，验证手段多以仿真和测试为主。对于已知的危害场景的确认部分，则需要通过验证结果证明其残余风险在可控合理的范围内。这一部分的内容，对于SOTIF来讲，其实属于相对比较容易解决的问题，本质上和功能安全解决问题的思路是一样的，只是对象和危害根源不同而已。对于未知危害场景的评估，主要是未知场景的确认，目的是确认来自未知危害场景的残余风险满足接受准则并具有足够的置信度(见ISO 21448，第11章)，这部分是SOTIF最难解决的问题，也是和功能安全相比，全新的存在的内容。对此，ISO 21448也没有太多的解决办法，只能依靠大量的长期测试进行确认，以极大的数据量覆盖未知场景，包括一些非常极端的小概率场景。SOTIF成果评估(见ISO 21448，第12章)，主要是对 SOTIF 活动产生的工作成果的完整性、正确性和一致性进行评审，给出并确认发布建议，包括“接受”、“有条件接受”或“拒绝”SOTIF发布的建议。这部分内容和功能安全中的第8.2.4章节认可措施有点类似，主要是对SOTIF流程和各阶段工作成果进行审核和评估。该部分属于ISO 21448，第13章内容，主要是发布之前定义现场监控流程，以确保运行期间的 SOTIF.场监控流程的程度需要根据驾驶自动化等级、预期功能的复杂程度以及危害的严重程度进行预期。 对于较低的驾驶自动化等级，通常的市场监管程序可能已足够。 但对于较高的驾驶自动化等级，需要额外的手段，例如自动驾驶数据存储系统(DSSAD)/汽车事件数据记录系(EDR)和车载/远程安全监控系统等。这些手段可以监测和记录车辆的性能和行驶情况，并提供实时的安全监测和控制，以确保自动驾驶车辆的安全和可靠性。
好书推荐：
