功能安全|端到端E2E保护整理笔记

发布于 2023-5-12 11:10
浏览
0收藏

2.4端到端保护

在分布式系统中,如果发送方和接收方之间的安全行为安全取决于此类数据的完整性,则发送方和接收方之间的数据交换可能会影响功能安全(请参阅本章开头的“信息交换”故障示例)。因此,此类数据应使用机制进行传输,以保护其免受通信链路内故障的影响。

2.4.1故障模式

根据ISO26262,对于在不同软件分区或ECU中执行的每个发送方或每个接收方SWC,可以考虑以下与信息交换相关的故障:


  • 信息重复;
  • 信息丢失;
  • 信息延迟;
  • 信息插入;
  • 伪装或不正确的信息地址;
  • 信息顺序不正确;
  • 信息损坏;
  • 从发送方发送到多个接收方的非对称信息;
  • 来自发送方的信息仅由接收方的一部分接收方接收;
  • 锁定访问通信通道。

功能安全|端到端E2E保护整理笔记-汽车开发者社区

图12:端到端保护


端到端保护的概念假设与安全相关的数据交换应在运行时受到保护,以防止通信链路内故障的影响(见图12)。此类故障的示例包括随机硬件故障(例如CAN收发器的寄存器损坏)、干扰(例如由于EMC)、在ECU内部和外部(例如在网关上)实现VFB通信的软件内部的系统故障(例如RTE、IOC、COM和网络栈)。


在端到端库中考虑以下与通过通信网络进行消息交换相关的故障。

故障模式

描述

信息重复

一种通信故障,被信息接收到不止一次。

信息损失

一种通信故障,是信息或部分信息从传输的信息流中移除的。

信息延迟

一种通信故障,如果收到的信息晚于预期。

信息插入

一种通信故障,被附加信息插入到传输的信息流中。

信息伪装

一种通信故障,被非真实信息接受为接收方的真实信息。

寻址不正确

一种通信故障,如果信息被不正确的发送方或不正确的接收方接受。

信息序列不正确

一种通信故障,用于修改所传输信息流中信息的顺序。



信息损坏

一种更改信息的通信故障。



从发件人发送到多个接收方的非对称信息

一种通信故障,如果接收方确实从同一发送方接收到不同的信息。



来自发送方的信息仅由接收方的子集接收

一种通信故障,一些接收方没有收到信息



阻止访问通信通道

一种通信故障,即对通信通道的访问被阻止。



表7:通信网络的故障模式32


32SWC端到端通信保护库规范,V3.2.1,R4.1修订版3,第3章4.3.3

2.4.2描述

从 SWC的角度来看,通过RTE传输数据的行为类似于简单的点对点连接。然而,这种抽象的实现需要一个由软件层、通信堆栈、驱动程序和底层硬件组成的高度复杂的基础设施。随着复杂性的增加,故障的潜在来源的数量也在增加。


使用端到端检测机制时,假定在通信过程中必须保持安全相关数据的完整性,从而保护数据免受通信链路内故障的影响。


端到端保护最重要的方面是保护功能的标准化和机制的灵活适用性。本章将介绍ECU内部和ECU之间的安全数据通信机制,端到端保护的概念。


End-2-End保护的架构实现如下:由应用数据组成的数据要素在发送方端扩展,并带有其他控制信息(End-2-End标头)。控制信息通常包含校验和、计数器和其他选项。扩展数据要素提供给RTE进行传输,如图13所示。它显示了端到端的原理,但不是实现所需的所有细节。特别是为了简单起见,省略了RTE数据转换器来编码/解码复杂数据要素。

功能安全|端到端E2E保护整理笔记-汽车开发者社区

图13:RTE33的数据要素


数据要素通过针对应用数据处理End2-End标头的内容,在接收方进行验证。在处理接收到的数据要素并接受为正确后,将删除控制信息并将应用数据提供给目标 SWC。错误处理在接收方上执行。


33SWC端到端通信保护库规范,V3.2.1,R4.1修订版3,第3章8.1

2.4.2.1端到端配置文件

AUTOSAR指定一组标准化且可配置的端到端配置文件,这些配置文件实现一组保护机制并为附加的End2-End标头指定数据格式。


端到端配置文件使用以下数据保护机制的子集:


  1. CRC校验和,由CRC库提供;
  2. 顺序计数器在每个传输请求处递增,在接收方端检查该值是否正确递增;
  3. 活体计数器在每个传输请求处递增,如果该值发生任何更改,则在接收端检查该值,但不检查正确的递增。
  4. 通过端口发送的每个端口数据要素的特定ID(系统全局,其中系统可能包含多个ECU)。
  5. 超时检测:接收方通信超时和发送方确认超时


在AUTOSAR标准中指定了端到端配置文件,配置文件1具有两个变体,即End-2-End配置文件2和End-2-End配置文件4。未来发布的版本还将指定配置文件5和6。


只能使用标准化的端到端配置文件,非标准端到端配置文件只能在特殊情况下使用,例如旧版软件。


表8中对端到端配置文件1的保护机制描述如下:

机制

描述

故障模式

计数器

4位计数器随着每个SendRequest的增加而递增。显式发送此值。

信息重复、删除、插入、不正确的顺序

超时

使用非阻塞读取,接收方可以确定计数器的值是否已增加。

删除、延迟




数据ID

每个发送方-接收方端口都有一个唯一的16位ID,用于CRC计算。CRC计算如图14所示。不会显式发送数据ID值。由于ID仅在发送方和接收方已知,因此CRC计算只能由相应的通讯协议正确执行。

插入,地址故障

CRC

对所有数据要素、计数器和数据ID执行CRC校验和(8位)计算。显式发送此值。

信息损坏




表8:端2端轮廓1中的机制


图14说明了如何在端到端配置文件1中执行CRC计算。数据ID的值计算到CRC值中,因此通信伙伴必须使用相同的数据ID来正确验证消息的CRC校验和。

功能安全|端到端E2E保护整理笔记-汽车开发者社区

图14:端到端配置文件1中的CRC计算


尽管数据ID的长度为16位,从而导致大量单独的数据ID,但CRC校验和的长度仅为8位。这意味着不同的数据ID将生成相同的CRC校验和,从而限制独立数据ID的数量。


如果消息被路由到错误的目标,例如由于网关中的位翻转,并且数据ID产生相同的CRC校验和,则接收方将接受误导的消息,假设当前计数器值和消息的长度都是正确的。针对寻址故障的基础保护范围已减小。此故障模式称为伪装。


可以限制数据ID值,以便在CRC校验和中没有重叠。但是,这会将独立数据ID的数量限制为255个。


端到端配置文件2在使用数据ID保护机制时采用不同的方法。每个发送方-接收方端口对都有一个数据ID列表。序列计数器的当前值确定使用哪个数据ID。


需要适当选择数据ID,以增加可以检测伪装的消息数。但是,8位数据ID和计数器值将重叠,从而将独立数据ID和计数器值的数量限制为256。


如果单个错误接收的消息不违反系统的安全目标,则End-2-End配置文件2允许防止伪装成更多数量的消息。

机制

描述

故障模式

序列号(计时器)

4位计数器随着每个SendRequest的增加而递增。显式发送此值。

意外消息重复、消息丢失、插入消息、重新排序

消息用于CRC的密钥计算(数据ID)

8位(未显式发送)用于CRC计算的数据ID是预定义列表的一个要素,取决于计数器的当前值。数据ID列表对于每个数据要素都是唯一的,并且只有发送方和接收方知道。

插入消息,伪装

安全代码(CRC)

对所有数据要素、计数器和数据ID执行CRC校验和(8位)计算。显式发送此值。

消息损坏,插入消息(伪装)

超时(由SWC实现的检测和处理)

超时检测必须由SWC实现。

消息丢失、消息延迟

表9:端到端配置文件中的机制2


AUTOSAR支持高达4kB的PDU,可通过TCP/IP堆栈或通过FlexRayTP、CANTP等的TP服务。端到端配置文件1和2支持符合ASIL-D标准的传输,最高可达30或42字节PDU,因为8位CRC校验和较短。


AUTOSAR版本4.2.1引入了新的端到端配置文件。端到端配置文件4专为符合ASIL-D标准的长数据传输而设计。这可以通过使用特殊的32位CRC多项式来支持。此多项式优于广泛使用的IEEE802.3CRC,因为它为长数据提供了更高的汉明距离。

机制

描述

故障模式

计数器

16位计数器随着每个SendRequest的增加而递增。显式发送此值。

意外消息重复、消息丢失、插入消息、重新排序

CRC

32位CRC是在整个E2E报头(不包括CRC字节)和用户数据上计算的。显式发送此值。注意:此CRC多项式与FlexRay、CAN、LIN和TCP/IP使用的CRC多项式不同。

消息损坏,插入消息(伪装)

数据ID

对于ECU网络中的特定数据要素,32位数据ID应是唯一的。显式发送此值。

插入消息,伪装

超时(由SWC实现的检测和处理)

接收方读取当前可用的数据,即检查是否有新数据可用。然后,通过计数器,接收方可以检测通信丢失和超时。

消息丢失、消息延迟

表10:端到端配置文件中的机制4


端到端配置文件4标头提供以下控制字段,这些字段与受保护的数据一起传输。

功能安全|端到端E2E保护整理笔记-汽车开发者社区

图15:端到端配置文件4接头


与E2E配置文件1和2相反,由于数据包没有标准大小,因此存在数据长度的显式传输。引入16位长度字段以支持可变大小的数据,这些数据在每个传输周期中可以具有不同的长度。此外,还有数据ID的显式传输。

2.4.2.2端到端状态机

通过使用End-2-End配置文件的check函数对应用数据处理End-2-End标头的内容,在接收方端验证数据要素。它确定此周期接收的数据是否正确,并在检测到故障时提供其他信息。


AUTOSAR版本4.2.1引入了一个状态机,它有助于确定接收到的应用数据是否可以接受,并提供更详细的信息。引入了一个新的抽象级别,因此应用接收通信的整体状态,而不是处理每条消息的状态。


新的状态机支持丢失或重复数据包数、可恢复和不可恢复的通信故障以及通信初始化的可配置设置。图16说明了状态机的设计和功能。

功能安全|端到端E2E保护整理笔记-汽车开发者社区

图16:端到端状态机

2.4.2.3端到端保护库的集成

为了正确使用端到端库,可以使用不同的解决方案。它们可能取决于RTE、COM或其他基础软件模块的完整性以及其他软件/硬件机制(例如内存分区)的使用。


端到端库可用于保护通过端到端保护包装器在SWCs之间交换的安全相关数据。


此外,End-2-End库可用于通过COM标注来保护与安全相关的I-PDU。


也有可能出现混合情况,其中某些数据要素在SWC级别受到保护(例如使用End-2-End保护包装器),而某些数据要素使用COM End-2-End标注。


在AUTOSAR版本4.2.1中引入的RTE数据转换器还可用于在RTE级别保护ECU之间复杂数据要素的数据交换。

2.4.2.4端到端保护包装器

端到端保护库可用于在RTE级别保护SWCs之间的数据通信。为此,端到端保护包装器充当Rte_Write的包装器,并Rte_Read功能(提供给SWC)。端到端保护包装器封装 SWC的Rte_Read/Write调用,并使用端到端库保护数据交换。


在这种方法中,每个与安全相关的SWC都有自己的附加子层(.h/.c文件对),称为End-2-EndProtectionWrapper,它负责将复杂的数据要素编组到与相应的IPDU相同的布局中(用于ECU间通信),并用于正确调用End-2-End库和RTE。请参见图17。


使用端到端保护包装器允许在SWC之间使用VFB通信,而无需采取进一步措施来确保VFB的完整性。此类SWC之间的通信可以在ECU内(这意味着在相同或不同的内核上,或在微控制器的相同或不同的存储分区内)或跨ECU(由VFB连接的SWC也使用网络)。


端到端保护是用于保护SWC通信的系统解决方案,无论使用何种通信资源(例如COM和网络、OS/IOC或RTE中的内部通信)。SWC的重新定位可能只需要选择其他保护参数,但不需要更改SWC应用代码。


此外,使用End-2-End保护包装器支持 SWC之间的安全通信,尽管存在可能不安全的通信软件堆栈。


注:端到端保护包装器不支持SWC的多次实例化。这意味着,如果SWC使用End-2-End保护包装器,则此SWC必须是单实例化的。此限制基于以下事实:SWC的多个实例具有相同的DataID,从而限制了基础保护机制的功能。

功能安全|端到端E2E保护整理笔记-汽车开发者社区

图17:端到端保护包装–通信概述

2.4.2.5传输管理器

在没有为COM和RTE提供操作完整性的ECU系统中,可以通过网络传输与安全相关的数据。


在发送方ECU上,有一个称为传输管理器的专用SWC,其中包含端到端保护包装器。传输管理器从相关的SWC收集与安全相关的数据,将它们组合起来,并使用端到端保护包装器保护它们。最后,它将组合和受保护的数据作为数据要素提供给RTE。请参见图18。


在接收方ECU上,传输管理器执行反向步骤以接收此类数据。


传输管理器取代了RTE和COM的特性,例如将数据要素合并到PDU中并确保数据的完整性。


注意:传输管理器SWC模块既不是End-2-End库的一部分,也不是AUTOSAR的一部分。此外,SWC和传输管理器之间RTE通信的完整性应受到其他措施的保护。

功能安全|端到端E2E保护整理笔记-汽车开发者社区

图18:传输管理器–发送方ECU

2.4.2.6 COM端到端标注

在此方法中,端到端库用于保护COM模块之间的数据交换。END-2-End库由COM通过COM End-2-End标注调用,以保护和检查I-PDU。标注使用适用于给定I-PDU的参数调用End-2-End库。请参见图19。


对于要保护和检查的每个I-PDU,都有一个单独的标注函数。每个标注函数“知道”需要如何保护和检查每个I-PDU。这意味着标注将调用End-2-End库函数,其设置和状态参数适用于给定的I-PDU。


该解决方案适用于RTE为ECU间通信提供的所有通信模型和多重性。与传输管理器相比,此解决方案只能用于提供COM和RTE操作完整性的系统。

功能安全|端到端E2E保护整理笔记-汽车开发者社区

图19:COM标注-概述

2.4.2.7 RTE数据转换器

在AUTOSAR版本4.2.1中引入的RTE数据转换器可用于保护ECU之间复杂数据要素的交换。


前面描述的端到端库调用机制之间的主要区别可以说明如下:


End-2-End保护包装器通过添加End-2-End标头的数据要素来扩展受保护的复杂数据要素。其他数据要素可由SWC查看,但被忽略。因此,RTEProtectionWrapper不支持保护单个信号,除非它们嵌入在复杂的数据要素中。


COM将复杂数据要素的各个信号映射到PDU中。使用COM标注,整个PDU的内容都受到保护。然而,最大PDU尺寸受互连总线物理特性的限制。


复杂的数据要素可以通过称为序列化的过程专门安排在字节数组中来准备传输。然后,可以使用端到端库作为单个部分来保护序列化的数据阵列。此外,序列化数据数组大小可以基于传输周期进行动态处理。

功能安全|端到端E2E保护整理笔记-汽车开发者社区

图20:RTE数据转换器-概述


如图20所示,RTE数据转换器接受来自RTE的复杂数据(发送方/接收方数据要素或带有其参数的客户端/服务端操作),执行可配置的数据转换链(如序列化、端到端保护、加密功能、压缩),并提供生成的字节数组,最终通过COM(或在ECU内部通信期间通过RTE)传输到接收方。端到端保护的数据转换由End-2-End转换器实现,该转换器在内部使用End-2-End库。


RTE数据转换器的完整配置通过用于ECU间通信的AUTOSAR系统模板和用于ECU内部通信的 SWC模板执行。生成的代码通过RTE完全生成和执行。SWC不必了解所使用的特定保护机制,除非需要详细了解检测到的故障。RTE数据转换器只能用于提供RTE操作完整性的系统。


注意:序列化数据阵列大小不受互连网络的PDU大小的限制,因为可以使用现有的转接协议传输大型数据阵列。


注意:单个数据转换是在数据数组而不是复杂数据要素上执行的,因此序列化是RTE数据转换器执行的是第一个和相应的最后一个数据转换。

2.4.3检测与响应

与端到端通信保护相关的功能在AUTOSAR4.0中作为标准库实现。此库提供端到端通信保护机制,使发送方能够在传输之前保护数据,并使接收方能够在运行时检测和处理通信链路中的错误。


当使用端到端库时,通信故障的检测被发送到接收方。


注:AUTOSAR文档“应用级错误处理说明”提供了有关错误处理的其他信息。在文档中,解释了如何执行错误处理以及可以从何处获取所需数据(例如替代值)。此外,本文档还提供了有关如何在AUTOSAR中执行 OS-Applications/分区终止和重新启动的详细说明(用户手册)。

2.4.4限制

  1. 仅正确使用端到端库不足以实现安全的端到端通信。用户独自负责证明所选配置文件为所考虑的网络提供了足够的错误检测功能(例如通过评估硬件失效率、误码率、网络中的节点数、消息的重复率和网关的使用)。
  2. SWC之间通过RTE进行的通信不仅仅是简单的点对点连接。必须考虑其他故障模式,例如数据转换中的RTE错误,过滤,缺少通知,客户端-服务端通信中的参数顺序错误以及传输延迟。在开发安全相关系统时,还必须考虑这些失效模式。
    本地RTE通信可以通过其他机制防止上述某些故障,例如采用内部分区和其他安全机制和措施的RTE。
  3. 由于运行时开销,对ECU的所有 SWC通信使用端到端保护可能会令人望而却步。此外,与DataID的唯一性相关的限制可能会由于伪装而阻止在配置文件1和2上使用此方法。
  4. 端到端保护不保证数据真实性,因为端到端配置文件不在控件数据中包含时间戳。


文章转载自公众号:软件赋能汽车

分类
标签
收藏
回复
举报
回复
相关推荐