当前位置: 代码网 > it编程>游戏开发>ar > 自动驾驶功能安全:AUTOSAR入门--E2E通信保护协议

自动驾驶功能安全:AUTOSAR入门--E2E通信保护协议

2024年08月04日 ar 我要评论
功能安全需要考虑通信失效造成的影响,因此E2E通信保护协议被提出,以满足功能安全要求;简单介绍E2E通信保护协议机制。

自动驾驶功能安全:autosar入门–e2e通信保护协议

  1. 功能安全需要考虑通信失效造成的影响,因此e2e通信保护协议被提出,以满足功能安全要求;

  2. 简单介绍e2e通信保护协议机制。

  3. 附赠自动驾驶最全的学习资料和量产经验:链接

1e2e通信保护协议的由来

如果系统的功能安全依赖于数据的完整性,那么发送方(sender)和接收方(receiver)之间的数据交换就可以对系统的功能安全造成影响。根据iso 26262 part 6的 附录d:信息交换章节,对于信息交换的接收方或发送方,一般需要考虑以下失效模式:

image

引自[1]

这里,对上述的这些失效模式稍作解释:

  • **信息重复:**多次收到同一条信息;

  • **信息丢失:**传输的信息流中,信息或部分信息被移除;

  • **信息延迟:**信息接收比预期晚;

  • **信息插入:**传输的信息流中,额外信息被插入;

  • **伪装:**非真实信息被接收方接收为真实信息;

  • **不正确寻址:**接收了不正确的发送方的信息或被不正确的接收方接收了信息;

  • **信息序列不正确:**修改了传输的信息流中的信息序列;

  • **信息损坏:**改变信息;

  • **从发送方发送到多个接收方的非对称信息:**接收方从同一发送方接收到了不同信息;

  • **来自发送方的信息仅由一部分接收方接收:**有些接收方没有接收到信息;

  • **阻塞访问通信通道:**通信通道的访问被阻塞。

这些失效一般由软件故障,随机硬件故障和瞬态故障引起。

  1. **软件故障:**像通信栈模块,rte等软件可能存在故障,而这些故障是系统性的,可能发生在系统生命周期的规范,设计,制造,运行和维护的任一阶段,并且在情况(例如根本原因的触发条件)相同时,它们总会出现,其后果可能导致通信失败,比如发送数据中断,接收器溢出等故障。

  2. **随机硬件故障:**通常是电气过载、退化、老化的结果或暴露于硬件部件的外部影响(例如环境压力)。随机硬件故障无法完全避免,但可以评估其概率并且可以实施适当的技术措施(比如诊断)。

  3. **瞬态故障:**由外部影响或环境应力引起,包括emi、esd、湿度、腐蚀、温度或机械应力(比如振动)等影响。

对应基于autosar架构的通讯部分,上述的故障表现如下示意:

image

引自[4]

上图包括软硬件导致的通信失效,其中硬件导致的通信失效有:

  • h1:通信的物理网络存在故障;

  • h2:是通信网络的接口存在电磁兼容性问题;

  • h3:微控制器故障,例如上下文切换时寄存器失效等

软件导致的通讯失效有:

  • s1: rte生成代码出错

  • s2: com服务层代码出错;

  • s3: 通信接口层和通信的驱动层之间可能存在问题;

  • h3:微控制器故障,例如上下文切换时寄存器失效等.

针对这些通讯失效,在autosar中就提出了e2e通信保护协议,即在系统运行过程中,动态地识别软硬件故障引起通信失效,保证ecu之间以及ecu内部不同核之间,不同swc 之间数据的安全通信。

image

引自[2]

基于e2e需求,e2e通信保护协议采用结合crc(循环冗余校验),counter(计数器),timeout monitoring(超时监控)和data id来实现,如下所示:

e2e保护机制检测出的失效模式
counter信息的重复,丢失,插入,不正确的序列,阻塞
time monitoring信息的丢失,延迟,阻塞
data id + crc信息的伪装,不正确寻址,插入
crc信息的损坏,不对称

具体这些机制是如何能够检测出对应的失效呢?

关于深入crc原理的资料:

crc(循环冗余校验码)简介与实现解析 - 知乎 (zhihu.com)

循环冗余检验 (crc) 算法原理 - cheney shue - 博客园 (cnblogs.com)

【脑冻结】crc我就拿下了 - poiu_elab - 博客园 (cnblogs.com)

(31条消息) 我学习crc32、crc16、crc原理和算法的总结(与winrar结果一致)_xiaogugood的博客-csdn博客

a painless guide to crc error detection algorithms

考虑到e2e通信保护协议需要涵盖各种大小的交换数据和不同类型的物理总线介质。因此就创建了多种e2e profiles(配置文件),即每个profiles包括一组保护机制,如下所示:

image

引自[3]

在[3] e2e protocol specification 中可以详细了解到8中e2e profiles 1,2,4,5,6,7,11,22的定义。这些e2e profiles是根据iso26262开发,用于与安全相关的项目,没有特定于某控制器,可以满足asil d需求的安全相关通信(之前思考一个问题:对于不同asil等级,需要采用哪种e2e profiles,我觉得都可以,因为每种e2e profiles都满足asil d等级,就看各家如何选取,谁有补充么?)。

2 e2e通信保护协议机制

以e2e profiles 2为例,它包含3个保护方式:分别是循环冗余校验,计数器和数据id,如下:

image

引自[3]

这四种e2e机制可检测出的失效如下:

image

引自[3]

这套机制是如何运行呢?借助[7]解释如下:

image

image

(0)

相关文章:

版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站仅提供信息存储服务,不拥有所有权,不承担相关法律责任。 如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 2386932994@qq.com 举报,一经查实将立刻删除。

发表评论

验证码:
Copyright © 2017-2025  代码网 保留所有权利. 粤ICP备2024248653号
站长QQ:2386932994 | 联系邮箱:2386932994@qq.com