安全在每个领域都是一个永恒的话题,汽车也不例外,而随着最近几年汽车电动化、智能化和网联化的发展,汽车安全也越来越受到用户及开发人员的重视,安全的要素也是多方面的,例如用户可能关心在使用车机系统时的隐私安全、打开ACC等辅助驾驶功能时的人身安全等;站在攻城狮的角度则会关注和考虑整车E/E架构、硬件以及软件等方面的可靠和安全,
比如硬件的EMC和随机故障、软件功能设计及控制器内部和外部的通讯安全等等。
每个安全要素作为系统目标的重要组成部分只为保证整车的可靠性和安全性,从而保护用户的人身安全。
对单个控制器的而言,其功能设计要求的实现不仅涉及自身内部功能模块的数据交互,还涉及与其他控制器之间进行数据的传输和通讯,而如何保证数据传输的正确性从而避免非期望的输出和控制呢?针对该问题,方式也有很多
例如我们CAN通讯的Checksum和RollingCounter校验就是一种相对比较简单和粗糙的安全保护措施,这次简单聊下AutoSAR中的E2E保护。
E2E介绍
E2E(End-to-End)保护是一种端对端保护机制。
举个例子:控制器中某个安全关键性功能模块的输出计算要依赖于内部某个非安全性的模块或其他安全等级要求不高的硬件通过总线传输过来的数据,因安全相关数据可能因通讯故障而丢失或篡改,那么如何保证数据交换的正确性呢?
此时就可借助E2E保护。从上面的例子,我们可大体知道,数据传输的链路主要存在如下三种:
-
不同控制器之间的数据传输
-
控制器内部ASW与ASW之间的数据传输
-
控制器内部ASW与BSW之间的数据传输
E2E保护既可用于控制器内部功能模块之间的数据保护,也可用于不同控制器之间的数据保护。
在整个链路里面,会存在硬件和软件相关的两种故障源,典型的软件相关故障源有如下几种:
-
S1: 因RTE带来的错误
-
S2: 因COM自动和手工代码引入的错误
-
S3 :网络堆栈错误
-
S4: 跨核通讯IOC或者OS的错误
硬件相关的故障源则有:
-
H1:通信网络故障
-
H2:电磁兼容性导致通信网络的接口故障
-
H3:微控制器故障,例如上下文切换时寄存器失效等
通过采用 E2E 通信保护机制可以在运行时,实时检测到通信链中出现的错误,E2E 库提供了相关的保护验证机制来保证与功能安全相关的通信。
AutoSAR标准里,采用E2E保护的算法是在E2Elibrary中实现的,调用者要负责该库使用的正确性,AutoSAR E2E可将通过RTE发送的安全相关数据元素加上保护控制流,并校验从RTE接收到的安全相关数据元素是否正确,若存在问题还需报出错误供负责接收的SWC做相应处理。
三种实现方式
在 AutoSAR标准中,E2E 保护的实现有三种不同方式:
基于E2EPW方式-SWC之间
基于E2EPW方式-ECU之间
什么是 E2E 保护 ? (qq.com)
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)