简介:道路千万条，安全第一！
万讲解智能汽车的电子电气安全，从智能汽车为什么做安全，怎么做，谁做，以及相关安全标准的介绍和内在关系，让大家全面了解智能汽车的安全体系。文中穿插了一些个人经历和观点，可供新手参考，老手回复。
一、为什么要做
1.1政策导向:
根据世界卫生组织的报告，每年道路交通事故造成的死亡人数达到125w，而在中国，有25w人死于交通事故。2017年，联合国发起的2030年可持续发展议程设定了到2020年将这一数字减少一半的目标，人类的事故率为10-6。业内分析，无人驾驶只有在事故率至少达到10-9的情况下才会被外界接受。
随着驾驶辅助系统和自动驾驶功能普及率的提高，预计2025-2040年期间将出现人机混合驾驶的状态。在这种背景下，车辆的安全性显得尤为重要。
中国工业和信息化部近日发布《智能网联汽车生产企业及产品准入管理意见》，明确要求“加强汽车数据安全、网络安全、软件升级、功能安全和预期功能安全管理”。
1.2监管导向:
目前智能驾驶汽车的安全性是制约其落地的重要因素之一。不同国家对智能驾驶汽车的态度不同，不同地区的国家也出台了一些法律法规，比如:
欧洲自动驾驶法规:
日本自动驾驶汽车相关法律法规:
美国自动驾驶相关法律法规:
法律法规很多，我都没看过。一句话:安全很重要，不符合规定禁止上路！
1.3用户导向:
智能汽车最终商业化的大部分是出行服务。用户除了乘坐体验，更关心产品的安全性，智能汽车的事故会被媒体放大，更容易引起消费者的担忧。这也是为什么所有主机厂和科技公司在推广智能驾驶产品的同时，都强调产品的安全性。
总结
对于所有这些因素，默认情况下，该行业遵循最先进的标准系统:ISO 26262，21448和21434。全文从安全的“三座大山”入手。
第二，做什么
2.1流程合规性:
为什么要做流程合规？
汽车电子电气安全的前提条件是在产品设计的各个环节控制人的失效，即“系统性失效”。对于汽车电子电气安全来说，99%的问题来自系统性故障。避免系统失败的有效手段是依赖过程，开发过程必须遵循Aspice和26262。流程的约束是什么？简而言之:流程让工程师把事情做对，做对的事情！
这也是当前业界热衷于Aspice/26262/21434工艺认证的重要原因。
2.2产品一致性:
目前国内汽车圈流行产品认证，使产品获得相应的证书。有企业宣称三电控制器、智能驾驶域控制器、芯片、操作系统符合26262-X、21434-X、CSMS、WP29。这里需要强调的重要一点是，单个产品的标准遵从性开发大多基于功能安全SEOOC或网络安全OOC。这是什么意思？产品的上层需求是建立在假设的基础上的，是指供应商分析并假设上层可能提出什么需求，然后开发其产品，但其需求并不真正来自上层需求。此时，甲方应确认产品的“假设需求”是否与自身需求真正匹配，做到需求正确、完整、可验证、可追溯。
另外，认证这个词在欧美汽车圈几乎不存在。BBA、通用汽车等。不热衷于认证，但是看审核和考核的过程和结果。可能还是国内汽车圈认证的时代吧！
总结:
首先需要强调的是，ISO 26262、21448和21434不是一种技术，而是一种法律标准和方法论。对于ISO 26262，21448和21434，过程符合性和产品符合性两者缺一不可。产品要整合到安全设计中，经过测试和确认，审核和评估才能通过。认证不是强制性的。
三。如何做
安全流程以ISO 26262为基准，划分的流程是ISO 21434和is based；我们的工作方法遵循26262概念:
定义功能/相关项目/资产
危险事件/威胁场景识别
设计安全概念
硬件和软件安全要求的实现
测试验证
整车确认
安全档案的编制
过程中的审计和评估
注:三者对应的问题类别不同，导致技术实现不同，但流程相似。
下面硬核分析L3功能开发中的三个典型安全案例:
L3功能安全设计的典型案例
L3以下的传统ADAS功能意外地在没有ASIL电平的情况下退出，但是HWP意味着驱动器不在循环中。它能后退吗？退出条件怎么设计？
SEOOC设计:
功能定义:HWP可以长时间奇数运行，速度0-120kph。功能退出的条件:司机踩刹车，超过ODD。
危害分析与风险评估:HWP系统意外出口，大曲率弯道场景，车辆惯性行驶，驾驶员稍有分心但无法及时接管，脑补场景:S3+E4+C3=ASIL D
安全概念:
为了简化架构模型，我们先做一个假设01:所有激活条件都满足，只有制动踏板状态可能不违反SG01。安全概念设计如下:
如果能实现以上SR，安全理念会不会很完美？
回答:没有！考虑到司机不小心碰到刹车踏板，司机还处于免提状态，这样安全吗？所以，这不是一个合格的安全概念设计！
安全概念的优化:
①法规ALKS 6.2.4章解释:本法规要求L3功能的退出需要在特定时间段内两次确认单向切换，或者可以采用两路同时输入功能的方式退出；同时，L3功能退出时，要求保证驾驶员侧向控制可控，侧向控制处于接管状态。
②考虑到上述cover安全架构的不足和ALKS 6.2.4的要求，增加了全程监控和判断条件，安全架构优化如下:
上述安全策略的设计既满足了ALKS对L3功能需要两个出口的要求，又满足了安全功能被人分心误用的情况。另外，策略中还要定义司机的车控优先级，这里就不细说了。
声明:
以上设计向大家传达了一个理念:安全设计是一个严谨的系统工程，所有的标准都要学会并灵活运用。同时，对于L3功能，不仅要考虑车的故障，还要注意ADS操作中人的误操作。
L3预期功能安全设计的典型案例
以HWP的主动变道功能为例，按照21448开发流程实现如下:
功能定义:当前车速持续低于车速80%，时间超过10s。车辆开始计划变道，选择目标车道，左侧优先；初始架构是5R+1V
SOTIF危害分析风险评估:当角度雷达漏检时，后方有异常车辆驶来，不符合变道条件，车辆自主变道存在碰撞风险，s > 0；C > 0，风险与SOTIF有关。
缺陷识别和触发条件识别:角度雷达对异常车辆识别漏检率高，角度雷达分辨率低，“点云”稀疏，触发条件为异常车辆。
功能改进:
综合考虑后，最终选择方案一。
1方案示意图，假设摄像机布置在正后方:
验证与确认策略:①定义验证目标，如:10万公里错误触发主动变道少于一次；②定义测试方法，如路试。
验证:选择方案1进行验证，进行功能测试、逻辑测试和具体场景测试，验证方案的有效性。如果测试通过，判断条件为S * C = 0；如果测试失败，将更新功能设计，如改变摄像头位置，优化传感器融合算法，或使用其他方案。
车辆确认:长期路试，确保验证目标的实现。
SOTIF发布:类似26262的安全案例，使用GSN/其他形式提供证据链，闭环安全工作。
手术后SOTIF的改进:在功能性手术中，如发现新的异常或功能不足，需分析问题原因或制定措施。
总结:
以上内容阐述了21448的开发过程和项目实践，很有参考价值。
L3网络安全设计典型案例
以HWP的主动变道功能为例，按照ISO SAE 21434和SAE J3061开发流程实现如下:
定义:如索蒂夫或萨福所述
资产识别:ADS控制器融合算法、ADS控制器状态机、制动踏板状态、脱手检测信号、角度雷达、摄像头、汽车高精度地图定位等。
资产性质和违规造成的损害场景:
威胁场景和攻击路径
攻击可能性和影响
网络安全要求和保护级别
网络安全设计
上述网络安全设计只是初步列出了网络安全的重要考虑事项，具有参考价值。
四。谁来做
要明确安全发展的作用，就要结合安全发展过程。第三章提到了安全开发流程:
定义功能/相关项目/资产
危险事件/威胁场景识别
设计安全概念
硬件和软件安全要求的实现
测试验证
整车确认
安全档案的编制
过程中的审计和评估
安全是一个非常严谨的系统工程，需要和各个环节的工程师并肩作战，最佳实践的开发工程师兼职。一方面，安全本质上是产品的一种属性，安全需求是功能需求的子集，所以脱离产品开发的安全设计会让安全形同虚设；另一方面，开发工程师是一线人员，对产品设计和测试有很深的理解。毕竟，他们技能的深度取决于他们对产品的了解。
只知道标准和流程是幻想。做项目管理/培训可以接受，但是做产品安全设计绰绰有余。系统安全工程师需要了解系统，软件安全工程师需要敲代码，正确的人做正确的事。专业+专注才是专家！
动词 （verb的缩写）相关安全标准与三大安全标准的联系
ISO TR 4804
ISO 4804的前身是“安全第一(Safety _ First _ for _ Automated _ Driving)”，由宝马发起，Aptiv、奥迪、百度等11家公司起草。本白皮书参考ISO262622143421448，定义了12项顶级安全原则，然后从12项安全原则中抽象出13项能力，并把这13项能力
标准想法如下:
12项顶级安全原则概述:
为了实现12项顶级安全原则，智能驾驶系统需要13项能力来支持12项安全原则，分为故障安全能力和故障降级能力。
注:13个能力的详细解释在此不再赘述。读者应参考ISO 4804。标准有明确的答案，通俗易懂。
下一步是将13项功能映射到系统架构中，以形成初步的安全架构:
注意:开发功能安全时，要基于正向导出每个元素的ASIL水平，不能用这种通用架构移植到自己公司的产品上来宣称感知符合ASILB，决策SWC符合ASILD，因为不同的架构即使是同一元素也会导致不同的asil。
总结:笔者认为ISO TR 4804是典型的德国安全理念，遵循瀑布式发展，从顶层目标一步步分解，通过层层验证最终实现顶层安全原则。这个标准对智能驾驶的安全工程师很有指导意义，尤其有利于21448的发展。用“人与人的相识只需十步”这句话来评价这个标准是非常恰当的！
推荐指数:☆☆☆☆☆
推荐指数:☆☆☆☆☆
UL 4600
UL 4600是全球首个自动驾驶评测标准，2020年发布的第一版，也是基于26262、21448、21434。该标准有望成为L3和L4级别自动驾驶的综合安全评估框架。UL 4600保持技术中立的态度，不强制使用任何类型的技术，并允许在过程中的灵活性。它提供了一个非常完整的清单，所谓的做什么
标准的第8部分和第12部分对产品安全开发和测试有很大的参考价值，提供了智能驾驶需要考虑的要点，极大地避免了开发者遗漏一些“安全点”，很大程度上避免了系统故障。4600-8和4600-12对应的是4804-5和4804-6，两者差不多，粗粒度4804，细粒度4600。
此外，值得注意的是，4600还支持环境之外的元素，不限于整车产品。一般适用于系统、零件、软件和硬件，类似于26262的SEOOC。
我觉得UL4600会是自动驾驶商业化的安全保障。在不久的将来，或许只有UL 4600认证的车辆/产品才会被保险公司承保，这或许会成为自动驾驶商业化的催化剂。
推荐指数:☆☆☆☆☆
推荐指数:☆☆☆
常州艾利克斯电子科技有限公司
UNECE-R157是欧盟首个L3自动驾驶的官方法规。它由包括欧盟和日本在内的全球60多个国家的成员共同制定。该标准以安全为核心，对自动驾驶汽车的技术要求、安全要求、审核和测试做出了相关规定。它于2020年6月发布，自2021年1月起在这60多个国家和地区生效。
ALKS的大多数要求可以追溯到4804的高级要求。此外，ALKS增加了量化要求，如不同车速下的跟车距离要求、紧急制动的要求以及非紧急MRC的减速度值。
笔者认为，该标准主要限制了功能的开发，会对功能性能和性能参数的设置产生影响。对于出口车辆，自动驾驶系统策略的开发应符合ALKS。同时，如果产品已经按照26262、21448、21434进行了开发，且策略符合ALKS，则间接符合ALKS的安全要求。
推荐指数:☆☆☆
推荐指数:☆☆☆☆☆
IEEE 2846
IEEE 2846标准基于Intel提出的责任敏感安全模型。英特尔高级首席工程师Jack Weast是这个工作组的负责人，发布时间未定。
RSS的四个原则:
1.与前车保持纵向安全距离。
2.与附近的车辆保持水平安全距离。
3.驾驶礼仪
4.注意视觉盲区。
读者可能会问，以上的安全原则不就是人类司机驾驶的原则吗？没错！RSS是基于人类驾驶的常识，然后将上述原理中的安全临界点进行数学表达，以保证自动驾驶车辆不会发生事故，从而使自动驾驶车辆做出安全决策。
RSS模型如下:
上图菱形RSS模型用于判断ADS决策的输出结果是否满足安全距离的要求。如果是，则控制指令会传递给ADS域控制器的横向和纵向控制模块，其本质是“决策结果的安全检查”，最终起到安全确认的作用。
RSS的垂直安全距离示例:
更糟糕的情况场景:自驾巡航，前车紧急制动8.5m/s 2，驾驶员反应时间1.2s，自驾减速假设5m/s 2。
根据RSS模型的计算，不同车速下生成的安全距离，下图第二列是车速，第一列是安全距离。当车速为100km/h时，跟车距离为99.06 mm，RSS模型得出的理论值与高速公路车速的安全跟车距离非常接近，也印证了RSS安全理念符合当前的行车要求和安全性。
总结:目前Mobieye正在积极推进RSS模型，也有企业参与其中，不断优化模型参数，未来该标准将在业界大放异彩。
话题讨论:特斯拉的影子模式+RSS模式会发生什么？
推荐指数:☆☆☆☆
推荐指数:☆☆☆
其他的
随着智能驾驶的蓬勃发展，安全相关的细分市场标准层出不穷，具体如下:
有兴趣的同事自行了解，如果需要标准文本，可以在微信官方账号联系工作人员。
总结:
2262、21448、21434是汽车电子安全的灵魂，是高阶的安全概念、玄学、通用套路，而4804、4600、ALKS、RSS是专注于自动驾驶的安全标准。
2262，21448，21434，就像金庸武侠小说《倚天屠龙记》中甘昆的大招。有了这门武功的加持，学习其他武功将事半功倍，而拥有九阳神功可以让安全标准更加完善！
不及物动词摘要
自动驾驶技术被认为是人工智能的终极应用之一，产品的商业化通常要经历三个阶段:第一阶段，理论突破，从理论上证明实现的可行性；第二阶段，技术突破，产品涉及的各方面技术成熟，尤其是通用人工智能的发展；第三阶段，工程条件和可持续发展的商业模式。
我一直认为现在的自动驾驶还处于第二阶段。短期来看，从功能/预期功能安全的角度分析感知问题仍然是最大的瓶颈。单个传感器的准确率和召回率仍然无法满足自动驾驶的要求，多传感器融合算法也无法覆盖某些角落情况。从长远来看，随着车路协同技术的进步，网络安全将是安全的最大威胁，所以安全问题的解决任重道远！
引用李俊院士的话:我们不仅要看到自动驾驶的光明面，也要看到它的弱点。还有很多安全问题需要解决，大家都在烧柴。需要整合国家汽车产业上下游企业的力量，在政府和产学研各界的共同努力下，提升我国智能网联汽车的整体安全性能。
