对"智能网联汽车 组合驾驶辅助系统安全要求"国标徵求意见稿的反馈 -要帮助车厂
杨福宇 yfy812@163.com 2025-12-27
公开征求《智能网联汽车 组合驾驶辅助系统安全要求》强制性国家标准的意见是2025-9-17公布的，意见要在2025-11-15前送出。可是我了解此事已迟，只能马后炮了。
#第一点意见是通信系统IP故障后果可能不适当地由车厂背锅
标准有一个编制说明，我国相关系统搭载率的快速增长加速了标准化的进程，编制说明中的介绍表明，立项后几乎每月开一次工作会，做了大量工作才提出了这个徵求意见稿。
编制说明P3/34
这个标准对标的是欧盟标准UN R171，因此如果有意见就等同于对欧盟标准UN R171有意见了。为此我也去了解一下UN R171。
我对外国的标准没有恐高症，一切以数据说话。例如CAN：ISO11898-2:2022添加了CAN XL内容，其中有电源短路的隐患(PDF) Conflict in Data Field of CAN XL V1 2022 (https://www.researchgate.net/publication/365945077_Conflict_in_Data_Field_of_CAN_XL_V1_2022)，Conflict in CAN XL system due to DLC receiving error V2 （https://www.researchgate.net/publication/385749571_Conflict_in_CAN_XL_system_due_to_DLC_receiving_error_V2）对CAN的安全隐患为什么要改掉CAN的error passive和bus off V1_-CSDN博客（https://blog.csdn.net/yfy812/article/details/149198472?spm=1001.2014.3001.5502），对于以太网标准IEEE 100BASE-T1,100BASE-TX有(PDF) Achilles' Heel of 100Base-T1：Link re-establish time of 200ms。（https://www.researchgate.net/publication/394361426_Achilles'_Heel_of_100Base-T1Link_re-establish_time_of_200ms）这些问题为什么存在可以有多种解释，例如随着研究的深入有新的发现，例如涉及经济利益的牵扯故意放水...所以要让社会各界放心，不得因为对照了欧盟标准UN R171就说可以。其中最重要的一点是如何管理通信系统（在本标准中是传输链定义中的一种）的功能安全测试。
UN R171的内容有可控性要求：
这个要求隐含了驾驶员的输入能保证送达控制对象，也即车内通信系通100%正常。
在我国的徵求意见稿中更明确的有如下定义
P6/134
为实现"响应能力"，通信系统是必不可少的，因此应该认为，通信系统的设计也是本标准覆盖的系统，包括CAN和Ethernet。例如硬件选择，协议选择，冗余设计等等。
P83/134中明确有对通信故障作测试的要求（共8类）
P73/134
通信系统的设计中用到了CAN IP，在CAN IP的故障状态下实现"安全概念"是困难的，厂商将受限于技术水平与成本考虑来尽力做好。
在标准中未见到(p83/134表C3中提到的)C.2.8.1.3的接受准则-遗漏还是未定？
P79/134 C.2.8.1.3缺失
这个标准的困难在于无法把通信引起的失效和功能系统设计、制造中的缺陷通过测试准确地分别清楚，造成不达标时原因的误判。
例如通信中断引起的故障：
1.Achilles' Heel of 100Base-T1：Link re-establish time of 200ms_-CSDN博客
现代网联车的EE架构用以太网在各DCU或ZCU间传信息，然而以太网非常依赖于收发的同步，一个symbol错将更新进解扰器状态，使扰码器与解扰器状态失去同步，然后收发扩大为很多个错，造成link错，二次7637-3干扰间仅隔90ms，小于复原需要的200ms，可能造成连续重建link失败；1）即使用环网拓扑，可能其间同时有新的链link断，环网崩断。通信中断会远超200ms，超过功能安全要求的事故处理容许时间，使用户的通信系统冗余设计失败；2）即使时间稍短，正在转向过程中发生故障，车也可能偏离道路方向，使本标准的考核失败，车厂背锅。
造成symbol错的原因有车设计上的问题，例如抗干扰的处理，例如电源系统产生的干扰大了；例如通信系统元器件质量（共模电感的差模输出超指标）；例如接插件的双绞线解绞太松；等等车厂的问题。
但是矛盾的主要方面是选用的以太网协议本身的缺陷：出错之后把错误扩大化了（200ms的停制服务），才会引起检测结果超标。
这就是说检验不合格时可能把以太网通信IP的责任归到车厂，而车厂要花更多的精力去使symbol错减少。
【又：涉及《汽车以太网100Mbps物理层接口（PHY）芯片技术要求及试验方法》】
2.为什么要改掉CAN的error passive和bus off V1_-CSDN博客
在ISO26262-11:2018 Road vehicles-function safety- part11: guidelines on application of ISO26262 to semiconductors , table30 (p74/188) 列出了对通信外围接口的要求 ,其中指明了包括CAN。CAN的BUSOFF不是安全状态，它将中断通信，直接背离ISO26262的要求：消息收到太迟（COM_RX_FM3:Message transferred too early/late）。
CAN的出错也是这样：例如车厂设计上的疏忽，CANH-CANL线缆长度差太大（接近1米：model 3)传送时间差5ns，本来的共模干扰就变成差模干扰信号了，只要很小的共模干扰就会引起CAN 出错。虽然CAN的出错可以重发，纠错的后果比较好，胜过其他通信协议，保证了全系统无时差的全局数据一致性。可是每次出错都有出错的计数，达到255后就进入busoff，停止收发。这个CAN的busoff不是安全状态，是设计缺陷，造成长时间的通信中断。这里出错频繁是车厂责任，而扩大为长时间通信中断是CAN IP的责任。
以太网和CAN的通信中断可以引起闭环系统开环失控，它们都可以造成未预期的加速、减速。自然也会影响本标准测试的结果，例如障碍物探测与响应能力等等。
记得大众双离合器设计时规定CAN通信失效时（包括CAN IP busoff造成的失效）停在都不啮合状态，导致高速公路突然失去动力的例子吗（L1级别的隐患 ）
#第2点意见是标准不适当地要求车厂提供设计细节，可以有替代方案
P14/134有一条设计好像管宽了：
4.4.2 车辆制造商应按照附录C的要求，提供可控性的设计说明。
附录C是关于功能安全设计细节，属于车厂的技术机密，上报该内容增加了泄密机会，或向国外泄漏，或将使懒汉得利，侵犯了车厂的利益也有碍于国家车业的长远利益，因此要慎重处理。对功能安全能否达标应着重在测试方法上，例如ISO7637-2.-3那样，是否达标不是卡的设计你是如何，用了什么方法，而是实测是否达标。
本标准有多种方法来验证功能是否达标，我认为应该以产品实测为主，仿真之类会受有意徊避或考虑不周导致模型失真，而不能代表真实性能。还不如碰撞测试实打实的公平。
这里建议一个不需要车厂提供功能安全设计机密的通信信号丢失的测试方法：
1线束电磁干扰引起CAN、以太网丢帧对功能安全影响。在车运动下（干扰源存在下），观察功能能否实现。这代表了本标准范围的功能与通信功能同时测试下的后果。不分开作结论，而是留待第2步。同时在线束选定的位置测试现场的电磁干扰，以便第2步测试时选择开关位置、频度做参考。
2车实物单独的功能测试：将测试车的线束分段，加入该段可控通断的高速电子开关（具体那些段由第1步干扰源位置及可能影响最重的节点确定），组成在车未运动状态（无自生EMI）下全车的功能系统，同时模拟正常的通信（包括正常的数据值和总线负载率，可能需要替代的信号源）。这个系统的通信可以由测试软件输入控制通信通断（代替上述1的电磁干扰），测试软件输入控制通断时长可以不那么长，以代表不同的CAN IP性能（例如取消BUSOFF）。从而可观察到车厂本辅助控制功能设计的后果（去除了CAN IP缺陷后的后果）。
这个测试方案需要较大的投资和人力投入，但比起泄密的损失还是值的。而且高速电子开关方法也可以用于元器件故障的设定，例如控制其电源来模仿其故障。这种方法甚至可以推广到无人驾试车的功能安全性能测试。L1级的故障原因留传到L3，它还在吗！？是驴子是马拿出来溜溜。
；