智能汽车的数据安全有规矩了吗（万字阐述智能驾驶汽车安全体系）

引言：道路千万条，安全第一条！

万字长文讲解智驾汽车电子电气安全，从智能汽车为什么做安全? 做什么? 怎么做? 谁去做? 及相关安全标准简介与内在联系，让大家全面的了解智驾汽车的安全体系，文中穿插一些个人经验及看法，供新手参考、老手复盘。

一、Why to do1.1 政策导向：

世界卫生组织（WTO）报告指出：每年因道路交通事故导致的死亡人数达到125w，而中国则是25w人死于交通事故，2017年联合国发起的2030年可持续发展议程确定了至2020年将这一数字较少一半的目标，人类的事故率为10^-6，业界分析认为无人驾驶至少要达到10^-9的事故率（航空业安全水平）才会被外界认可接受。

随着驾驶辅助系统和自动驾驶功能渗透率的提高，预测2025-2040期间存在人和机器混合驾驶的状态，这种背景下车辆的安全性尤为重要。

我国工信部近期印发的《智能网联汽车生产企业及产品准入管理意见》明确提出要求“加强汽车数据安全、网联安全、软件升级、功能安全和预期功能安全管理”。

1.2 法规导向：

目前智能驾驶汽车的安全问题是制约其落地的重要因素之一，不同国家对智能驾驶汽车的态度不尽相同，不同区域国家也纷纷出台一些法规，如：

欧洲的自动驾驶相关法规：

序号	法规政策名称
1	《自动驾驶汽车认证豁免程序指南》
2	欧盟安全法规 2007/46/EC

日本自动驾驶汽车相关法规：

序号	法规政策名称
1	《关于自动驾驶系统的公共道路测试指南》
2	《自动驾驶汽车安全技术指南》
3	《自动驾驶的公共道路测试使用许可标准》

美国自动驾驶相关法规：

序号	法规政策名称
1	《AUTOMATED Vehicle 4.0》
2	《自动驾驶法案》
3	《美国通过革命性技术提高安全运输的愿景法案》

法规较多，本人也没有一一拜读，总之一句话：安全很重要，不合规禁止上路！

1.3 用户导向：

智能驾驶汽车最终的商业化大部分还是出行服务，用户除了关心乘车体验，更关心产品的安全性，且智能驾驶汽车的事故会被媒体放大，更容易引起消费者的担忧，这也是为什么各个OEM、科技公司在宣传智能驾驶产品的同时都强调其安全性。

小结

以上种种因素，行业内默认遵循state-of-art的标准体系：ISO 26262、21448、21434三大安全体系，全文以安全“三座大山”展开。

二、what to do2.1 流程符合性：

为什么要做流程符合性？

汽车电子电器安全的前提条件是在设计产品的各个环节控制人的失效，也就是的“系统性失效”，对于汽车电子电器安全而言99%的问题来源于系统性失效，规避系统性失效的有效手段就是依靠流程，开发流程须遵循Aspice、26262，那流程究竟约束了什么呢？ 简而言之：流程使工程师正确的做事，做了正确的事！

这也是为什么目前行业热衷Aspice/26262/21434流程认证的一个重要原因。

2.2 产品符合性：

目前国内汽车圈比较流行的是产品认证，使产品获得相应证书，一些企业宣称三电控制器、智驾域控制器、芯片，操作系统等符合26262-X、21434-X、CSMS，WP29，这里要强调的一个重要的点，单一产品的标准符合性开发多是基于功能安全SEOOC或者网络安全OOC开发，什么意思呢？其产品上层需求是基于假设，是供应商去分析、假想上层（整车/系统/子系统）可能会提出什么要求，然后开发其产品，其需求并非真正来自上层（整车/系统/子系统）需求，此时甲方应确认该产品的“假设需求”是否真正匹配自身的需求，使需求符合正确性、完整性及可验证、可追溯性。

另外，认证一词在欧洲和美洲汽车圈几乎不存在，BBA、GM等并不热衷认证证书，而是看audit、assessment的过程和结果，可能在国内汽车圈仍旧是一个看证的时代！ （正因如此德系、美系、法系等第三方咨询认证公司在中国业务做的风生水起）

小结：

首先强调一点，不论是ISO 26262、21448、21434都不是一种技术，只是法规标准，是一种方法论，对于ISO 26262、21448、21434而言，流程符合性和产品符合性二者缺一不可，产品要融入安全设计、经过测试确认，且audit、assessment通过即可，认证并不强制（除非甲方要求）。

三、How to do

安全的流程基础是ISO 26262，而分出来的流程上有ISO 21434，ISO 21448；工作的方法论都是遵从26262理念：

• 定义功能/相关项/资产
• 危害事件/威胁场景识别
• 设计安全概念
• 软硬件安全需求实现
• 测试验证
• 整车确认
• 安全档案编制
• 过程中的审计和评估

注：此三者的对应问题类别不同，导致所需的技术实现也不同，但是流程上是大同小异。

下面硬核解析3个L3功能开发中的典型的安全案例：

L3功能安全设计典型案例

传统的L3以下的ADAS功能非预期退出无ASIL等级，但是HWP是驾驶员处于不在环（不能及时接管）状态，是否可以立退呢？退出条件如何设计呢？

SEOOC设计：

• 功能定义：HWP在ODD内可长时间脱手、脱脚运行，车速0-120kph，功能退出条件：驾驶员踩制动、超出ODD。
• 危害分析和风险评估：HWP系统非预期退出，大曲率弯道场景，车辆惯性运行，驾驶员轻度分心但无法及时接管，脑补场景：S3 E4 C3=ASIL D。

SG01

避免非预期退出ADS功能

ASIL D

100ms

• 安全概念：

为了简化架构模型，我们做一个假设Assumption01：所有激活条件均满足，只有制动踏板状态可能发生故障违反SG01，安全概念设计如下：

ID	安全需求描述	ASIL	分配	FHTI（ms）
SR01	ESP应探测自身故障（导致非预期发出踏板被踩下信号），故障报警；	D	ESP	80
SR02	如果ADS收到ESP故障报警信息，忽略ESP踏板状态信号，信任备份（IBooster）踏板状态…	D	ADS	20
SR03	通讯E2E…	D	ESP&ADS	50
SR04	如果ADS未收到ESP制动踏板踩下信号，ADS禁止退出pilot功能；	D	ADS	80

如果以上SR均能实现，安全概念是否就完美了呢？

答案是：否！考虑驾驶员偶尔误碰制动踏板且驾驶员还处于脱手状态安全吗？ 因此这不是一个合格的安全概念设计！

• 优化安全概念：

①法规ALKS 6.2.4章节解读：该法规要求L3功能的退出需要一路开关在特定时间周期内进行2次确认，或者有2种方式同时输入（意味着需要2种形式的退出条件都满足）功能才可以退出；同时要求，L3功能退出时，必须确保驾驶员横向是可控制的，横向控制处于接管状态。

②考虑cover上述安全架构的不足（驾驶员误踩制动且处于脱手状态），以及ALKS 6.2.4要求，增加一路脱手监测判断条件，优化安全架构如下：

以上安全策略的设计既符合了ALKS要求的L3功能退出需要2路退出条件，同时也满足了功能安全的人员分心误用情况，此外、策略上还需要定义驾驶员车控优先，详细内容不在此详述。

声明：

以上设计传递给大家一个理念：安全设计是严谨的系统工程，各标准之间要活学活用，同时对于L3功能而言，不仅要考虑车的fault，还要重点关注人在ADS运行中的误用。

L3预期功能安全设计典型案例

以HWP的主动变道功能为例，按照21448开发流程实施如下：

• 功能定义：当前车车速持续低于本车车速80%，时间超过10s，本车开始规划变道，选择目标车道，左侧优先；初始架构为5R 1V
• SOTIF危害分析&风险评估：当角雷达漏检，侧后方有异形车辆驶来，不满足变道条件，车辆自主换道存在碰撞风险，S＞0；C＞0，该风险是SOTIF相关风险。
• 缺陷识别和触发条件识别：角雷达对异形车辆识别的漏检率偏高，角雷达分辨率较低，“点云”稀疏，触发条件是异形车辆。
• 功能改进（仅供参考）：

方案1	整车级方案	增加能覆盖侧后方区域的摄像头（如侧视摄像头），和角雷达形成异构冗余，感知融合降低漏检率。 注意：感知融合需要传感器强强联合，使漏检率更低，而不是强弱联合，否则会出现短板效应，传感器权重设计与优化是难点。
方案2	系统级方案	使用4D毫米波雷达，提高分辨率，要求召回率大于98%（仅为示意数值）。
方案3	功能限制	主动变道功能报警提醒，当符合主动变道条件，系统发起接管报警提醒，此方案会牺牲功能的舒适性，变道引起的频繁报警。

综合考虑，最终选择方案1

方案1示意，假设摄像头布置在正后方（仅示意，不作为设计参考）：

• 验证&确认策略：①定义validation target，如：10万公里误触发主动变道小于1次（仅为示例，数据不可信）；②定义测试方法，如路试
• 测试验证：选择方案1进行验证，进行功能测试、逻辑测试、具体场景测试，验证方案有效性，测试通过判断条件为S*C=0，测试不通过则更新功能设计如：更改摄像头位置，优化传感器融合算法，或者使用其他方案。
• 整车确认：长期路试，确保validation target（10万公里误触发主动变道小于1次）被实现。
• SOTIF发布：类似26262的safety case，使用GSN/其他形式提供证据链，安全闭环工作。
• 运行后的SOTIF改进：在功能运行中，如发现有新的异常或功能不足出现，此时需分析问题原因或需制定措施。

小结：

以上内容阐述了21448（SOTIF）开发流程以及项目实践，抛砖引玉。

L3网络安全设计典型案例

以HWP的主动变道功能为例，按照ISO SAE 21434及SAE J3061开发流程实施如下：

• 功能定义：如SOTIF或FuSa描述
• 资产识别：ADS控制器融合算法、ADS控制器状态机、制动踏板状态、脱手检测信号、角雷达、摄像头、汽车高精地图定位等
• 资产性质及违反造成的Damage Scenario：(仅列举2个例子)

	保密性	完整性	可用性
ADS控制器融合 算法	如违反，则： ADS控制器重要参数泄露，汽车地理位置及可能的路径暴露；	如违反，则： （1） 后方来车感知异常，汽车非预期变道造成碰撞 （2） ADS控制器无法准确获知后方来车，变道性能长期不可靠 （3） ADS控制器或需要更换	如违反，则： （1） ADS控制器融合算法无法利用，后方来车感知异常，汽车非预期变道造成碰撞 （2） ADS控制器无法准确获知后方来车，变道性能长期不可靠
ADS控制器状态机	如违反，则： ADS控制器状态机暴露，增大操控性被夺取可能；	如违反，则： ADS无法正常退出HWP模式，即使条件符合，此时整车被操控，影响乘员安全	如违反，则： ADS无法正常退出HWP模式，即使条件符合，此时整车被操控，影响乘员安全

• 威胁场景及攻击路径

• 攻击可能性及影响

• 网络安全需求及防护等级（举例）

ID	需求	防护等级
CS-01	防止ADS控制器融合算法的保密性受非法披露	CAL2
CS-02	防止ADS控制器融合算法的完整性受非法篡改	CAL2
CS-03	防止ADS控制器融合算法不可用	CAL2
CS-04	防止ADS控制器状态机的保密性受非法披露	CAL2
CS-05	防止ADS控制器状态机的完整性受非法篡改	CAL2
CS-06	防止ADS控制器状态机不可用	CAL2

• 网络安全设计

ID	防护举例
CS-01	AES128或AUTOSAR网络安全机制
CS-02	MAC采用或者AUTOSAR网络安全机制
CS-03	DDOS系统部署，整车监控
CS-04	AES128或AUTOSAR网络安全机制
CS-05	MAC采用或者AUTOSAR网络安全机制
CS-06	DDOS系统部署，整车监控

上述网络安全设计只是初步罗列了网络安全重要考量点，抛砖引玉。

四、who to do

定义安全开发的角色，需结合安全开发流程，第三章节提到安全开发流程：

• 定义功能/相关项/资产
• 危害事件/威胁场景识别
• 设计安全概念
• 软硬件安全需求实现
• 测试验证
• 整车确认
• 安全档案编制
• 过程中的审计和评估

安全是非常严谨的系统工程，需要和各个环节的工程师并肩合作，最优的做法的开发工程师兼职，一方面、安全本质上是产品的一个属性，安全需求是功能需求的一个子集，脱离产品开发的安全设计会使安全无用武之地；另一方面、开发工程师是一线人员，对产品的设计和测试有深刻的认识，毕竟、功力的深浅取决于对产品的认识程度。

只懂标准、懂流程属于花拳绣腿，做项目管理/培训尚可，做产品安全设计则心有余而力不足，系统安全工程师要懂系统，软件安全工程师要敲过代码，对口的人干对口的事，专业 专注才是专家！

五、相关安全标准与三大安全标准的联系ISO TR 4804

ISO 4804的前身是《Safety_First_for_Automated_Driving》，由BMW发起，联合Aptiv，Audi，baidu等11家单位起草编制，该白皮书参考ISO26262&21434&21448，定义了12条顶层安全原则，然后将12条安全原则抽象出13项能力，把13项能力逐步分解到系统和零部件，指导自动驾驶开发人员如何进行安全设计以及如何进行测试，最终闭环系统安全设计。

标准的思路如下：

12条顶层安全原则概述:

	principles of safety and cybersecurity (PSC)	解读	映射到开发要求
整车层面	PSC_01: 网络安全	避免智驾车辆受到网络安全的威胁；	设计符合21434
	PSC_02: 数据记录	当事故发生的时候， 自动驾驶系统状态记录有关的数据；	EDR黑匣子
	PSC_03: 被动安全	随着自动化等级提高，座椅位置、方向可能发生变化，也要考虑碰撞场景下的安全；	被动安全的考量
	PSC_04: 安全评估	验证和确认智驾系统依据26262、21434、21448导出的安全需求都被实现了；	审核 评估，包括流程和产品
系统层面	PSC_05: 安全运行	系统具备降级，失效可运行的能力；	降级策略设计，冗余设计
	PSC_06: 安全层	自动驾驶系统应识别系统限制，尤其corner case，然后移交驾驶权限，并做出应对以尽量减小风险；	OEDR能力 MRC能力
	PSC_07: 交通行为	智能驾驶车辆的行为是可解释的、可被行人/其他车辆理解的，遵守交规的；	整车级安全策略的设计、HMI设计（遵循ALKS法规）
	PSC_08: 运行设计域	ODD内的安全，以及ODD边界的识别，及时移交驾驶权限；	OEDR能力， HMI报警策略和接管策略设计；
人员层面	PSC_09: 用户责任（角色）	车辆的HMI要清晰显示当前驾驶模式，驾驶员应该清晰驾驶职责；	HMI设计（遵循ALKS法规）
	PSC_10: 驾驶员接管	驾驶员控制权优先；	驾驶员权限第一，控制器和执行器的仲裁设计；
	PSC_11:车辆发起接管请求给驾驶员	接管请求利于理解，如果驾驶员不接管，车辆能进入MRC（最小风险条件）；	HMI设计； MRC设计；
	PSC_12: 操作员与自动驾驶系统的依赖性	不同等级自动驾驶对车辆操作员的影响； 在自动驾驶行驶中和自动驾驶结束后，人车交互的依赖关系。	HMI设计； 接管策略设计；

为了实现12条顶层安全原则，需要智能驾驶系统具备13项能力支撑12条安全原则，这些能力分为失效安全能力（FS）和失效降级能力（FD）。

注：13项能力详细解释不在赘述，读者请参考ISO 4804，标准有清晰的回答，通俗易通。

下一步将13项能力映射到系统架构中，形成初步的安全架构：

（上图来源《自动驾驶安全第一白皮书》中文版）

注：开发功能安全的时候，要基于正向导出对每个要素的ASIL等级，不能使用此通用架构移植到自己公司的产品上，来宣称感知符合ASILB，决策SWC符合ASILD，因为架构的不同会导致即使是相同要素也会存在不同ASIL的情况。

总结：笔者认为ISO TR 4804是典型的德系安全理念，遵循瀑布式开发，从顶层目标逐级向下分解，层层验证最终实现顶层安全原则，该标准对于智能驾驶的安全工程师非常具备指导意义，尤其是对21448的开发大有裨益，“初极狭才通人复行数十步豁然开朗”这句话用来评价此标准非常合适！

推荐指数（ADS安全从业人员）：☆☆☆☆☆

推荐指数（ADS系统工程人员）：☆☆☆☆☆

UL 4600

UL 4600是全球首个自动驾驶评估标准，2020年发布的第一版，同样是以26262、21448、21434为背景（不会替代原标准），该标准预期成为L3、L4级别的自动驾驶综合安全评估框架， 4600保持技术中立的态度，不强制使用什么类型的技术且允许流程存在灵活性，它提供了一个非常完整的cheklist，也就是所谓的what to do但未说明How to do，被评估方需要提供声明、论点及证据来阐述产品的安全性。

标准的第8部分、第12部分对于产品安全性开发和测试很有参考价值，提供了智能驾驶需要考虑的点，极大的避免了开发人员漏掉一些“安全点”，很大程度上避免了系统性失效，4600-8和4600-12对应4804-5和4804-6异曲同工，4804颗粒度较粗，4600颗粒度较细，此部分对于26262及21448的开发极具参考价值。

另外、值得注意的是，4600也支持环境之外的要素，不局限于整车产品，通用适用于系统、零部件、软硬件，类似于26262的SEOOC。

笔者认为UL4600将是自动驾驶走向商业化道路的安全保障，不久的将来，或许只有通过4600认证的车型/产品才会被保险公司上保，这或将成为自动驾驶商业化的催化剂。

推荐指数（ADS安全从业人员）：☆☆☆☆☆

推荐指数（ADS系统工程人员）：☆☆☆

ALKS（Automated Lane Keeping Systems）

UNECE-R157是欧盟第一部关于L3级自动驾驶（0-60kph）的正式法规（以下简称“ALKS”），是由欧盟、日本等在内的全球60多个国家成员联合制定，该标准以安全为核心，对自动驾驶车辆的技术要求、安全要求、审计、测试等方面做出了相关规定， 于2020年6月发布，2021年1月起陆续在这60多个国家和地区中正式生效。

ALKS大部分要求能追溯到4804的high level要求，除此之外ALKS增加了量化要求，如：不同车速下的跟车距离要求，紧急制动以及非紧急MRC的减速度数值的要求。

笔者认为，该标准主要是约束功能开发，对功能表现和性能参数的设定会有产生影响，针对出口车型而言，自动驾驶系统策略的开发要符合ALKS，同时如果产品已经按照26262、21448、21434开发且策略符合ALKS，就间接符合了ALKS的安全要求。

推荐指数（ADS安全从业人员）：☆☆☆

推荐指数（ADS系统工程人员）：☆☆☆☆☆

IEEE 2846 (RSS)

IEEE 2846标准基于英特尔提出的责任敏感安全模型（Responsibility Sensitive Safety以下简称RSS），由英特尔资深首席工程师Jack Weast担任该工作组的负责人，发布时间未定。

RSS四大原则：

1. 与前车保持纵向安全距离

2. 与临侧车辆保持横向安全距离

3. 行车礼仪（即使自车有优先通过权，也让行）

4. 注意视野盲区（如：鬼探头场景）

读者可能会问，上述安全原则不就是人类司机开车的原则吗？没错！RSS就是基于人类驾驶常识然后把上述原则中安全临界点定用数学方式体现出来，确保自动驾驶车辆不会导致事故，使自动驾驶车辆作出安全的决策。

RSS模型如下：

（注意：RSS并不是驾驶策略而是安全模型）

上图中菱形RSS模型是判断ADS决策的输出结果是否符合安全距离要求，如果“是”控制指令会传递给ADS域控制器的横纵向控制模块，其精髓是“对决策结果安全检查”，最终起到安全确认的作用。

RSS纵向安全距离示例：

Worse case的场景：自车巡航行驶，前车紧急制动8.5m/s^2，驾驶员反映时间1.2s，自车减速度假定5m/s^2。

经RSS模型计算：生成的自车不同车速下的安全距离，下图中第二列是自车车速，第一列是安全距离，当车速为100km/h，跟车距离要求99.06mm，通过RSS模型导出的理论值和高速公路车速安全跟车距离（V＞100km/h，跟车距离大于100m）非常接近，也印证了RSS的安全理念符合当前的行驶要求以及安全性。

总结：目前Mobieye正积极推广RSS模型，部分企业已经参与其中不断优化模型参数，后续该标准或将在业界大放异彩。

话题讨论：当特斯拉的影子模式 RSS模型会发生什么？

推荐指数（ADS安全从业人员）：☆☆☆☆

推荐指数（ADS系统工程人员）：☆☆☆

其他

随着智能驾驶的蓬勃发展也陆续涌现出细分市场的安全相关标准，如下：

标准	描述
ISO 22737	针对低速L4，物流小车，无人巴士，无人环卫车等
CSAE 156-2020	自主代客泊车系统总体技术要求

有兴趣的同仁自行了解 ，如有需要标准正文，可以联系公众号人员。

小结：

26262、21448、21434是汽车电子电子安全的灵魂，是一种高阶安全理念、是形而上学，是放之四海而皆准的套路，而4804、4600、ALKS、RSS则是聚焦自动驾驶的安全标准。

26262、21448、21434好比金庸先生的武侠小说《倚天屠龙记》里的乾坤大挪移，有此武功的加持，学习其他武功（4804、4600、ALKS、RSS）会事半功倍，而身具九阳神功（智驾产品系统工程设计经验）则可以将安全标准运用的更加炉火纯青！

六、总结

自动驾驶技术被认为是人工智能的终极应用之一，而产品的商业化通常要经历发展三个阶段：第一阶段、理论突破，从理论上证明实施可行性；第二阶段、技术突破，产品涉及的方方面面技术成熟，尤其是通用人工智能（AGI）的发展；第三阶段、工程化条件具备和可持续发展的商业模式。

笔者始终认为目前自动驾驶还仍于第二阶段，短期看、从功能/预期功能安全角度（ISO-26262、21448）分析感知问题仍是最大的瓶颈，单传感器的准确率和召回率仍无法满足自动驾驶要求，多传感器融合算法也无法cover一些corner case，长期看、随着车路协同技术的推进，网络安全（ISO-21434）将是安全最大的威胁，因此安全问题的解决任重道远！

引用李骏院士一段话：我们既要看到自动驾驶光鲜的一面，也要看到其弱点，既尚存很多待解决的安全问题，众人拾柴火焰高，要整合全国汽车行业上下游企业的力量，在政产学研界的共同努力下，才能实现中国智能网联汽车整体安全性能的提升。

,