AUTOSAR_CP_SWS_E2ELibrary

简介和功能概述

本文档包含PRS E2E协议的特定平台实现要求。这包括所使用的接口和数据类型。
AUTOSAR Foundation文件849“E2E协议规范”中给出了功能规范的主要部分。
扩展协议规范的平台相关功能规范在以下小节中收集。
E2E保护的概念假设在运行时应保护与安全相关的数据交换免受通信链路内故障的影响。此类故障的示例包括随机硬件故障（例如CAN收发器的损坏寄存器）、干扰（例如由于EMC）和实现VFB通信的软件内的系统故障（例如RTE、IOC、COM和网络堆栈）。

通过使用E2E通信保护机制，可以在运行时检测和处理通信链路中的故障。E2E库提供了E2E保护机制，足以满足ASIL D要求的安全相关通信。
保护机制的算法在E2E库中实现。E2E库的调用方负责正确使用该库，特别是为E2E库例程提供正确的参数。
E2E保护包括以下内容：

• 它通过附加控制数据来保护要通过RTE发送的安全相关数据元素，
• 它使用该控制数据验证从RTE接收的安全相关的数据元素，以及
• 它指示接收的安全有关的数据元素有故障，然后必须由接收器SW-C处理。

为了提供解决灵活性和标准化问题的适当解决方案，AUTOSAR指定了一组灵活的E2E配置文件，用于实现E2E保护机制的适当组合。每个指定的E2E配置文件都有固定的行为，但它有一些功能参数的配置选项（例如，CRC相对于要保护的数据的位置）。

从以下位置调用E2E库：

1. E2E转换器（R4.2.1中引入的调用E2E的一种新的标准化方法）
2. E2E保护包装
3. COM E2E标注。

无论在哪里执行E2E，E2E保护都适用于数据元素。在与总线上传输的位布局相同的位布局上，对数据元素的串行表示执行E2E保护。这意味着：

• 如果使用E2E变压器，则串行化由E2E变压器以上的变压器执行（基于COM的变压器或Some/IP变压器）。
• 在使用E2E保护包装器的情况下，包装器需要将数据元素序列化为相应信号组的序列化形式（换句话说，包装器创建I-PDU的一部分，该部分表示信号组，同时表示数据元素）。
• 如果使用COM调用，则串行化由通信堆栈（RTE、COM）完成，因此调用直接在I-PDU中的串行化信号组上操作。

数据元素（和相应的信号组）要么完全受E2E保护，要么不受保护。保护它的一部分是不可能的。
I-PDU可以携带若干数据元素（以及相应的信号组）。可以独立地对这些数据元素的子集进行E2E保护。
根据ASIL D要求，单独适当使用E2E库不足以实现安全的E2E通信。用户仅负责证明所选配置文件为所考虑的网络提供了足够的错误检测能力（例如，通过评估硬件故障率、误码率、网络中节点的数量、消息的重复率和网关的使用）。

术语和缩写

除下表中列出的术语外，本文件中使用的所有技术术语均可在官方AUTOSAR词汇表[1，AUTOSAR_TR_Glossary]中找到。
具有本地范围的缩写词和缩写词不包含在AUTOSAR词汇表中，它们出现在下面的词汇表中。

引用文件

输入文件及相关标准规范

[1] Glossary
AUTOSAR_FO_TR_Glossary

[2] General Specification of Basic Software Modules
AUTOSAR_CP_SWS_BSWGeneral

[3] E2E Protocol Specification
AUTOSAR_FO_PRS_E2EProtocol

[4] Requirements on E2E
AUTOSAR_FO_RS_E2E

[5] Requirements on Libraries
AUTOSAR_CP_SRS_Libraries

[6] General Requirements on Basic Software Modules
AUTOSAR_CP_SRS_BSWGeneral

[7] List of Basic Software Modules
AUTOSAR_CP_TR_BSWModuleList

[8] Requirements on System Template
AUTOSAR_CP_RS_SystemTemplate

[9] Software Component Template
AUTOSAR_CP_TPS_SoftwareComponentTemplate

[10] Specification of ECU Configuration
AUTOSAR_CP_TPS_ECUConfiguration

相关文档

AUTOSAR提供了基本软件模块的通用规范[2，SWS BSWGeneral]，该规范也适用于E2ELibrary。
因此，规范SWS BSW General应被视为E2ELibrary的附加和必需规范。

约束和假设

限制

[3，AUTOSAR PRS E2EProtocol]中描述了有关E2E保护和可检测故障模式的一般限制。E2E配置2在R4.2.1中有一个新的设置偏移。可以在系统模板中配置此偏移量。然而，E2E配置文件2规范不支持偏移量不同于0的情况。E2E配置程序2的规范将在未来的AUTOSAR版本中固定，以支持可配置的偏移量。
“双数据ID配置”中的E2E配置文件1使用隐式2字节数据ID，在此基础上计算CRC8。由于两个不同2字节数的CRC可能会导致相同的CRC，因此用户必须采取一些预防措施。参见PRS_E2E_UC_0072和PRS_E2E.UC_0073。
E2E配置2使用隐式的1字节数据ID来计算CRC，该隐式的数据ID是根据计数器的每个值从数据ID列表中选择的。有关E2E配置文件2的DataIDList的使用和生成的详细信息，请参阅[3，AUTOSAR PRS E2EProtocol]。

E2E库的实施

E2E库的实施应符合汽车领域安全相关软件的开发要求。
分配给E2E库实现的需求的ASIL取决于特定系统的安全概念。根据应用程序的不同，E2E库至少可能需要符合ASIL A、B、C或D的开发流程。
因此，根据最高ASIL开发库可能是最有效的，这也使得能够将相同的库用于较低的ASIL。
应根据汽车领域安全相关软件开发的要求，实施和配置E2E库和调用它的代码（如E2E包装器、E2E调用、E2E变压器）的配置（包括其他子系统使用的配置选项，如COM信号到I-PDU映射）。

对其它模块的依赖性

所需的文件结构

E2E库应由以下文件构建：E2E.h（公共头）、E2E.c（公共部件的实现）、E2E_PXX.c（其中XX：例如01、02、…表示配置文件）和E2E_SM.c（用于E2E状态机）。
文件E2E_PXX.c和E2E.h应包含每个配置文件特定的实现部分。
以下要求与上述要求是多余的，但需要明确说明：
E2E库文件（即E2E_“.”）不应包括任何RTE文件。

对CRC库的依赖

需要注意的是，Crc库/Crc例程的函数Crc_CalculateCCRC8自R4.0以来一直是功能性的，即它在R3.2中不同，并且>=R4.0：
•有一个额外的参数Crc_IsFirstCall
•该函数具有不同的起始值和不同的XOR值（从0x00更改为OxFF）。

这导致给定缓冲器的计算CRC的不同值。
为了在>=R4.0和R3.2中获得函数E2E_P01Protect（）和E2E_P01Check（）的相同结果，同时使用不同功能的CRC库，E2E“补偿”CRC库的不同行为。这导致在>=R4.0和R3.2中E2E库对CRC库的不同调用。

功能规范

错误分类

库没有配置，因此无法禁用或启用对开发错误的跟踪。因此，不可能将库内部机制检测到的错误归类为开发或生产错误。此外，库不能调用BSW模块（例如DEM或DET）。因此，库内部机制检测到的错误会同步报告给调用方。请注意，CRC库和E2E库都不是BSW模块；库可以相互调用。

E2E库不应包含库内部机制，用于将错误检测追踪为开发错误。
E2E库应通过返回值向E2E函数的调用方报告库内部机制检测到的错误。

E2E库不得调用BSW模块进行错误报告（特别是DEM和DET），也不得用于任何其他目的。E2E库不得调用RTE。

开发错误

所有E2E库功能应使用以下错误标志：
0x80…0xFE范围仅用于扩展具有供应商特定返回值的AUTOSAR配置文件。

E2E函数E2E_PXXProtect（）/E2E_PXCheck（）的调用方应根据“E2E的调用方如何处理”一列处理SWS_E2E__00047中定义的错误/静态。

换句话说，E2E库本身没有定义任何集成错误。然而，E2E库的调用方使用E2E函数的返回值并进行相应的错误处理。

时序图

本章描述了调用方应该如何调用E2E库。它展示了如何使用E2E库来保护数据元素和I-PDU。

发送者

数据元素的发送者

下图指定了数据元素的发送方调用的涉及E2E库的总体顺序。发送器本身可以通过一个或多个模块/文件来实现。在图表之后，有特定于数据元素发送方的要求。

新数据元素可用后，在调用E2E_PXXProtect（）之前，数据元素的发送方应：
如果数据元素通信是ECU之间的，并且数据元素不是不透明的uint8数组，则E2E库的用户应将数据元素序列化为数组data。阵列数据的内容应等于I-PDU中相应信号组的串行表示的内容。
注意，在一个I-PDU中可以存在多个受保护的信号组。

为了满足上述要求，E2E库的用户需要知道RTE如何将与安全相关的数据元素映射到信号，然后由COM映射到I-PDU中的区域，以便能够回放这一步骤。这是一个相当复杂的活动，因为这意味着发件人需要执行“用户级”COM。

对于不同于不透明数组的数据元素的发送，E2E库的调用方应将数据元素序列化为data，然后调用E2E_ PXXProtect（）例程，然后将控制字段从data复制回数据元素。

从本质上讲，序列化涉及到数据复制。如果数据元素是不透明数组，则不需要对数组进行数据序列化，调用方可以将data元素强制转换为uint8*。然而，为了避免相对于其他数据类型对不透明数组进行特殊处理，实现者可以决定将数据元素的序列化也应用于不透明数组的data。
数据中控制字段的偏移量在软件组件模板元类EndToEndDescription中定义。

信号组级别的发送者

下图是发送者在信号组级别上涉及 E2E 库的整体序列。发件人本身可以通过一个或多个模块/文件实现(例如 COM 加上调用，或 COM 加上复杂的设备驱动程序)。
示意图显示了当 I-PDU 中只有一个 E2E 保护信号组时的示例，但是一般情况下可能有几个(每个信号组0或1个 E2E 保护)。在这种情况下，I-PDU 的发送方在每个受 E2E 保护的信号组上调用 E2E_PXXProtection。

接收者

关于下图中SYNC状态的说明：在循环9中，计数器值不再可信，因为NoNewOrRepeatedData超过了MaxNoNewOrRepeatedData。由此产生的行为类似于在循环9中检测到“计数器的意外行为”。因此，“计数器连续性检查”从周期10-11开始。

数据元素的接收者

下图指定了接收器在数据元素级别调用的涉及E2E库的总体序列。发送器本身可以通过一个或多个模块/文件来实现。在图表之后，有特定于数据元素发送方的要求。

如果数据元素通信是ECU之间的，并且数据元素不是不透明的uint8数组，则接收器应将数据元素串行化为数组data。数据的布局（内容）应与发送数据元素的相应I-PDU的布局相同。此外，接收器还应验证未在I-PDU中传输的所有比特（即，不存在于数据中的比特）是否等于0。

为了满足上述要求，接收器需要知道RTE如何将安全相关的数据元素映射到信号，然后由COM映射到I-PDU，以便它可以回放这一步骤。这是一个相当复杂的活动，因为这意味着发件人需要执行“用户级”COM“。
比特验证的一个例子：假设I-PDU中的10个比特由COM扩展为16比特信号，然后由RTE扩展为16位数据元素。在这种情况下，数据元素的6个最高有效位应为0。这应由接收方进行验证。

对于不同于不透明数组的数据元素的接收，E2E库的调用方应将数据元素序列化为data，然后调用检查例程。

信号组级别的接收者

下图总结了接收器在信号组级别上涉及E2E库的序列。
该图显示了当I-PDU中只有一个受E2E保护的信号组时的示例，但通常，可以具有其中的几个（每个信号组0或1个E2E保护）。在这种情况下，I-PDU的接收器在每个受E2E保护的信号组上调用E2E_PXXCheck。

配置规范

与所有AUTOSAR库一样，E2E库没有配置选项。库函数执行所需的所有信息都在运行时通过函数参数传递。对于函数E2E_PXXProtect（）和E2E_PXXCheck（），其中一个参数是Config，它包含保护数据的选项。
E2E库不应有任何配置选项。

附录：E2E库使用安全手册

本章包含在设计和实施安全相关系统时使用E2E库的要求，这些要求取决于E2E通信保护。

E2E配置及其标准变体

E2E库提供两个E2E配置文件。它们可用于ECU之间和ECU内部的通信。
由于E2E配置文件1有多个配置选项，因此这些选项的推荐/默认值定义为标准E2E配置1变体。
E2E配置文件1的任何用户应尽可能使用定义的E2E变体。

错误处理

E2E库本身不处理检测到的通信错误。它只检测单个接收到的数据元素的此类错误，并将这些信息返回给调用者（例如SW-C），调用者必须做出适当的反应。
应用程序错误处理的一般标准化通常是不可能的。
E2E库的用户（调用方），尤其是接收器，应为E2E库检测到的故障提供错误处理机制。

E2E库的使用方法

本节总结了使用E2E库所需的步骤。在AUTOSAR R4.0中，E2E库的使用不是由AUTOSAR方法定义的。有四个主要步骤，如下所述。

在第一步中，用户选择在给定系统中如何使用E2E库的体系结构方法（通过COM调用、通过E2E保护包装等）。第A.5章中介绍了几种使用E2E库的体系结构解决方案。

在第二步中，用户选择需要保护哪些数据元素或信号组，以及使用哪个E2E配置文件。原则上，所有被确定为安全相关的传输数据都是需要保护的数据。

在第三步骤中，用户确定要保护的每个选定数据元素或信号组的设置。设置存储在软件组件模板元类EndToEndDescription中。设置包括例如数据ID、CRC偏移。

1. 对于每个要保护的信号组，都有一个单独的EndToEnd Description实例，在系统模板中与ISignalIPdu元类相关联。
2. 对于要保护的每个数据元素，都有一个独立的End ToEndDescription实例，该实例与VariableDataPrototype、SenderCom-Spec和ReceiverCom-Spec元类间接关联。
   在第四个也是最后一个步骤中，用户生成（或以其他方式开发）必要的粘合代码（例如，E2E保护包装、COM调用），负责调用E2E库函数。粘合代码充当通信模块（如COM、RTE）和E2E库之间的适配器。

RTE SW-C级保护配置约束

在使用E2E库保护数据元素的情况下，RTE需要如何配置有一些限制。
如果保护发生在I-PDU级别，那么E2E侧对RTE配置没有限制。

SW-C级保护的通信模型

AUTOSAR RTE支持不同的通信模式，如客户端-服务器、收发信机、模式切换等。

SW-C级保护的多重性

E2E库不用于N∶1的发送器-接收器多重性。
如果使用E2E库来保护数据元素，则所选的多重性应为1:N或1:1。

显式访问

发送器-接收器SW-C通信在发送器不等待接收器的意义上是异步的。这意味着发送方将数据元素传递给RTE并继续执行——它不等待接收方接收数据——这是不可配置的。RTE在执行发送器的同时向接收器发送数据。

现在，问题是接收器如何获得数据。在AUTOSAR中有两种方法可以做到这一点，可在RTE中配置：

• 接收器等待新数据：它被阻止/等待，直到来自发送器的新数据元素到达（RTE通信模式“唤醒等待点”和“激活可运行实体”）
• 接收器从RTE获得当前可用的数据元素，即最新的数据元素（RTE通讯模式“隐式数据读取访问”和“显式数据读取存取”）

E2E配置文件1和2与所提出的E2E保护包装器一起提供超时检测（这是要处理的故障模式之一，例如消息丢失）。这是通过使接收器独立于数据的接收而执行，并通过使用E2E配置文件中的计数器来实现的。通过这种方式，如果例如数据元素丢失，则接收器可以看到，每次读取的数据元素都具有相同的计数器。然而，这要求接收器不仅仅在数据到达时被执行。

如果接收器是事件驱动的，则需要在接收器处使用超时机制。超时机制不是E2E库的一部分。

如果E2E库用于保护数据元素，则使用E2E保护包装访问的数据元素应使用激活“显式数据读取访问”（即不应使用激活的“隐式数据读取存取”）。

COM功能的使用限制

下表列出了COM功能及其简要说明，并提供了与本文档中所述的端到端通信保护相结合的使用限制分类。

注：此列表仅涵盖BSW模块COM与E2E库和E2E保护包装器的组合功能。它不涉及上述层的特征（例如, RTE）或使用E2E变压器的使用情况。后者通常用于BSW模块LdCom之上。

限制类别如下：

• “支持”表示（E2E COM Callout和E2EPW）都支持此功能。
• “依赖于用例”是指根据发送方和接收方的实际用例和配置，可能会使用/可用该功能。然而，必须分析实际系统的适用性及其对安全要求的影响。
• “不支持”表示至少有一种变体（E2E COM Callout或E2EPW）不支持此功能，或者故障模式可能被屏蔽。

附录： 关于使用E2E库的应用提示

为了能够正确使用E2E库，可以使用不同的解决方案。它们可能取决于RTE、COM或其他基本软件模块的完整性以及其他软件/硬件机制的使用。

用户负责选择满足其特定安全相关系统安全要求的E2E库使用解决方案。
基于本章所述解决方案的每个特定实施方案在使用前都需要进行功能安全性评估。

E2E库可以以不同的方式使用（每种方式在本章的单独章节中进行解释）：

• E2E保护包装-保护数据的非标准集成商软件，高于RTE（第B.1节）
• COM调用-保护I-PDU的非标准积分器代码（第B.2节）。
• 混合/未使用（第B.3节）
• RTE级的开箱保护（E2E转换器）（第B.4节）

也可以有混合场景，例如：

• 对于特定的数据元素，发送器使用E2E保护包装，接收器使用COM E2E调用（或反向）
• 在给定的ECU网络或一个ECU中：一些数据元素受E2E保护包裹保护，一些受COM E2E调出保护。

第一种情况适用于网络诊断（例如，当没有RTE的监控设备检查消息时），或者当其中一个通信伙伴没有RTE时。
最佳情况是可以保证RTE和COM传输/转换安全相关数据的操作完整性。简而言之，我们称之为安全的RTE和安全的COM。
本附件介绍了如何调用E2E库的两个示例性基本解决方案。
首先，这是通过一个SW-C或几个SW-C的专用子层（称为E2E保护包装，见B.1节）实现的。其次，这可以通过调用E2E库的专用COM调用来实现，以保护表示数据元素的信号组（称为COM E2E调用，见第B.2节）。
第B.3节说明了如何将需要保护包装接口的组件（第B.1节）集成到提供COM Callout解决方案的ECU上（第B.2节）。
AUTOSAR配置中提供了所有必要的选项，可以生成所述解决方案的代码，这些选项在[8，RS_SystemTemplate]和[9，TPS_SoftwareComponentTemplate]中定义。这包括例如I-PDU与数据ID的关联。

E2E Protection Wrapper

注意：E2E封装器方法涉及不受AUTOSAR标准约束的技术，并被高级E2E转换器方法（由AUTOSAR完全标准化）所取代。因此，新项目（没有遗留零件造成的遗留限制）应使用完全标准化的E2E转换器方法。
在这种方法中，每个与安全相关的SW-C都有自己的附加子层（它是.h/.C文件对），称为E2E保护包装器，负责将复杂的数据元素编组到与相应的I-PDU相同的布局中（用于ECU间通信），并负责正确调用E2E库和RTE。
E2E保护包装器的使用允许在SW-Cs1之间使用VFB通信，而不需要进一步的措施来确保VFB的完整性。
这种SW C之间的通信可以在ECU内（这意味着在微控制器的相同或不同的核上，或者在相同或不同存储器分区内）或者在ECU之间（通过VFB连接的SW C也使用网络）。
端到端保护是一种用于保护SW-C通信的系统解决方案，无论使用何种通信资源（例如COM和网络、OS/IOC或RTE内的内部通信）。SW-C的重新定位可能只需要选择其他保护参数，但不需要更改SW-C应用程序代码。
可以通过适当的软件/内存分区来优化E2E保护包装器的使用。
E2E保护包装器不支持SW Cs的多个实例化。这意味着，如果SW-C应该使用E2E保护包装器，那么这个SW-C必须是单个实例化的。

如果从E2E保护包装器（在数据元素级别）调用E2E库，则不允许多次实例化。对于使用E2E保护包装的AUTOSAR软件组件，在AUTOSAR软件部件描述中，属性supports SwcInternalBehavior的MultipleInstance应设置为FALSE。
E2E保护包装本身不是E2E库的一部分。然而，它的选择是标准化的。E2E保护包装器的大多数选项在[8，RS_SystemTemplate]中定义，其中一些选项在[9，TPS_SoftwareComponentTemplate]中。

应保证E2E保护包装器（用于传输/转换安全相关数据）操作的完整性。E2E保护包装器的函数是不可重入的，因此它们不能同时调用。不得同时调用每个E2E保护包装器函数。
为了实现上述要求，建议以仅从一个Runnable调用一个特定的E2E保护包装器功能的方式来设计SW Cs和E2E端口，即一个E2E保护包裹器应“属于”特定的Runnable。
注：E2EPW API函数的调用方应确保E2EPW的内部状态数据结构正确初始化。初始化可以通过ECU启动代码完成，也可以通过E2EPW初始化函数明确完成。

功能概述

E2E保护包装器作为提供给软件C的Rte_Write和Rte_Read功能的包装器。E2E保护包装器使用E2E库封装Rte_Read/Write调用和数据交换保护。
对于要传输的数据元素，有一组为发送方和接收方生成的包装函数（读/写/初始化）。
E2E保护包装器函数负责调用E2E库所需的数据结构的实例化和初始化、E2E库的调用和Rte_Read/Rte_Write函数的调用以及数据元素的序列化。
数据结构的初始化取决于特定的数据元素，例如要使用的数据ID或E2E配置文件。
函数E2EPW_Write_和E2EPW_Read_返回表示状态的32位整数。
下图显示了来自SW Cs的E2E库和E2E保护包装的总体使用流程。

转换器管理的应用场景

可以有一个中央SW-C来收集给定ECU上多个SW-C的安全相关数据，并通过网络将其组合传输。
在下面的ECU上，有一个名为Transmission Manager的专用SW-C，包含E2E保护包装。传输管理器从相关SW C收集安全相关数据，将其组合并使用E2E保护包装器进行保护。
最后，它将组合和保护的数据作为数据元素提供给RTE。
在接收器ECU上也可以有一个传输管理器，它为接收这种数据执行相反的步骤。
Transmission Manager SW-C模块不是E2E库的一部分，也不是AUTOSAR的一部分。



在本例中，对于SW-C1和SW-C2，不可见通信正在通过这样的传输管理器，它可以支持通信网络的可移植性并优化资源使用。只有通过AUTOSAR配置，才可见SW-C1的接收器和SW-C2中的接收器是SW-C3。
转换器管理器（作为安全相关软件组件）的实施应符合汽车领域安全相关软件开发的要求。

E2E管理器和转换管理器的应用场景

此应用场景与前一个类似，其中传输管理器被拆分为两个独立的SWC（E2E管理器和转换管理器）。该方案的优点是可以自动生成E2E管理器，并且转换管理器完全独立于E2E保护。
转换管理器是一个SW-C，负责数据转换，例如浮点到整数的转换。在发送器ECU上，E2E管理器负责组装所有要传输的数据元素，并通过E2E保护包装器对其进行保护。
在接收器ECU上，转换管理器负责通过E2E保护包装器检查数据，然后过滤掉接收器转换管理器不需要的数据。
E2E管理器和转换管理器SW-C模块不属于E2E库，也不属于AUTOSAR。

在上述示例中，发送器ECU的SWCs生成三个数据元素（数据El1、数据El2和数据El3），但是接收器ECU的SW Cs仅使用两个数据元素。未使用的DataEl3c未交付给转换管理器。
因此，如果由于例如系统进化，DataEl3的定义发生变化，则不需要改变接收器SW Cs（SW-C 5、SW-C 6和SW-C 7转换管理器）。
相应的系统配置描述如图B.7所示。注意，SW-C 7仅具有所需的数据元素作为输入。未提供未使用的数据元素（CRC、计数器、dataEl3c）：

可以自动生成E2E管理器的E2E保护包装。
E2E管理器的应用程序代码只负责将输入数据元素“路由”到输出数据元素，这也很简单，可以生成。对于上面的示例，E2E Manager的应用程序代码可能如下所示：

E2E Manager应具有前缀为Input或前缀为Output的复杂数据元素。具有输入前缀的数据元素和具有输出前缀的数据元之间存在一一对应的关系。
在上面的例子中，有Inputswc8和相应的Outputswc8。

输出数据元素应包含相应输入数据元素的原始数据元素的子集（特别是，它们可以相等）。
在上面的示例中，Outputswc8包含Inputswc8的属性子集。它不包含dataEl3c、crc或计数器。
对于输出复数据元素的每个基元数据元素，E2E管理器的（生成的）应用代码应将其写入从输入复数据元素对应的基元数据单元读取的值。
在上面的例子中，E2E管理器的应用程序代码将数据El1c和数据El2c从Inputswc8复制到Outputswc8。

转换管理器和E2E管理器（作为安全相关软件组件）的实施应符合汽车领域安全相关软件开发的要求。
接收器ECU处的E2E管理器SW-C应过滤掉ECU的SW-C未使用的数据元素。接收器ECU处的E2E管理器SW-C应仅将转换管理器SW-C使用的数据元素转发给转换管理器。

方法

注意：AUTOSAR的不同版本对COM类有不同的名称。下面的文本描述是通用的，以适应不同的版本，但图表略有不同（主要区别是类和对象的名称不同）。
在RTE合同阶段（即生成SW-C接口文件时），标准AUTOSAR RTE生成器为SW-C生成SW-C界面文件RTE_<SWC类型短名称>.h。该文件包含RTE生成的函数，如RTE_Write_

（）。对于该文件中用于传输安全相关数据的每个函数，Rte.h中都有相应的函数。
E2E保护包装器可以手动实现，也可以根据其描述生成/配置。生成E2E保护包装所需的所有必要信息都可以使用AUTOSAR模板（系统模板、SW-C模板、ECU配置）进行配置。
E2E保护包装器的生成可以在执行步骤“生成组件API”的同时完成，该步骤生成“组件API”。