用于ECU和/或测量设备之间的数据传输的方法

1.一种用于机动车辆领域中的电子控制单元和/或测量设备间的数据传输的方法，所
述电子控制单元在下文中被称为ECU，其特征在于，所述数据传输的架构被分成对配置、校
准和/或诊断数据进行操作的以软件实现的控制平面和传输测量数据和/或原型数据的以
硬件实现的数据平面，所述配置、校准和/或诊断数据在下文中称为CD数据，所述测量数据
在下文中称为M数据，所述原型数据在下文中称为RP数据，其中所述控制平面对于所述数据
平面表现为用于上行链路业务量的输入设备和用于下行链路业务量的输出设备，以及所述
数据平面从输入设备接收数据载送事件，在没有任何情境切换开销的情况下非常快速地使
这些事件串行化，执行一组泛化处理步骤并将数据载送事件分发到输出设备，其中数据事
件的服务质量（QoS）感知排队和调度仅在所述数据平面内执行。
2.根据权利要求1所述的方法，其特征在于，使用事务来传输所述CD数据。
3.根据权利要求1或2所述的方法，其特征在于，在无状态数据流中传输所述M数据和/
或所述RP数据。
4.根据权利要求1或2所述的方法，其特征在于，所述数据平面向和从所述ECU和/或测
量设备切换事务和/或流的命令和响应。
5.根据权利要求1或2所述的方法，其特征在于，在分布式测量、校准和诊断系统内执行
所述方法。
6.根据权利要求1或2所述的方法，其特征在于，所述方法适合于监视和/或控制机动车
辆内的ECU的操作。
7.根据权利要求1或2所述的方法，其特征在于，所述方法适合于监视和/或控制机动车
辆内的ECU间的数据传输。
8.一种电子控制单元接口模块，所述电子控制单元在下文中被称为ECU，所述电子控制
单元接口模块用于控制机动车辆领域中的ECU和/或测量设备间的数据传输，其特征在于，
所述ECU接口包括用于实现根据前述权利要求中的任一项的方法的装置。
9.一种用于监视和/或控制机动车辆的电子控制单元（ECU）的操作的测量设备，其特征
在于，所述设备包括根据权利要求8的ECU接口模块。
10.一种电子控制单元（ECU），其适合于连接到测量设备或连接到另一ECU，所述测量设
备用于监视和/或控制机动车辆的电子控制单元（ECU）的操作，其特征在于，所述ECU包括根
据权利要求8的ECU接口模块。

用于ECU和/或测量设备之间的数据传输的方法\n技术领域\n[0001] 本发明涉及一种用于机动车辆领域中的电子控制单元（在下文中称为ECU）和/或\n测量设备之间的数据传输的方法。此外，本发明涉及ECU接口模块、ECU和测量设备。\n背景技术\n[0002] 电子控制单元且特别是机动车辆中的引擎控制单元（ECU）的数目及其联网不断地\n增加。例如，新的动力传动系技术导致更快的控制回路且以太网正在开始补充或者甚至替\n换汽车中的传统互连技术，如CAN、FlexRay、LIN和MOST。\n[0003] 这些发展导致快速增加的数据吞吐量和对于ECU和嵌入式ECU接口模块的更有挑\n战性的实时要求。\n[0004] 下一代的ECU接口设备因此将从快速以太网走向分布式测量、校准和诊断（MCD）系\n统内的吉比特以太网。嵌入式快速原型（RP）系统将利用PCI Express技术来满足苛求的等\n待时间和抖动要求。\n[0005] 基于软件的服务质量（QoS）和协议处理的传统方式不能以所请求的性能跨多个层\n处理多种多样的协议。\n[0006] 从现有技术已知的传统汽车协议标准和对应的参考图是基于软件驱动客户端—\n服务器模式。在托管MCD应用软件或原型软件的强大的标准个人计算机上运行的客户端充\n当智能协议主机，并且嵌入式ECU接口模块中的服务器充当命令执行协议从机。\n[0007] 在已知汽车协议标准中，使用标准控制器硬件（CAN控制器、Flexray控制器、以太\n网媒体接入控制器或类似控制器）来仅实现服务器中的链路层。类似于网络层、传输层和汽\n车协议服务层的较高协议层全部以运行在实时操作系统的顶部上的软件来实现，该实时操\n作系统具有类似于直接存储器存取（DMA）的一些有限标准硬件支持。\n[0008] 在非常有限的中央处理单元（CPU）组内的不同链路层的顶部上实现多个协议层堆\n栈要求使用由底层操作系统提供的服务和软件线程方法来将与异步输入数据事件（帧）相\n关联的处理进行串行化。\n[0009] 然而，与软件线程相关联的串行化和情境切换开销限制了最大事件率。此事件率\n限制似乎是用于所有基于软件的实时系统的主要瓶颈。其导致用于原型应用的增加的IO等\n待时间和抖动、用于事务的增加的往返时间和由于得到的网络帧速率限制而引起的有限测\n量吞吐量。基于软件的实时系统中的性能优化是困难的，如果不是甚至不可能实现的话，因\n为用于减少情境切换开销的事件率的抑制使原型和控制平面的低等待时间要求恶化。使用\n多核CPU技术以便增加软件处理能力使ECU接口模块功率消耗要求恶化且不能有效地促进\n单个高比特率数据会话（例如单个传输连接协议（TCP）连接），因为会话的分组排序禁止对\n其分组的并行处理。\n发明内容\n[0010] 因此，本发明的目的是提供一种用于上面确定的数据传输的方法，使得能够实现\n加速的数据传输，特别是快速（低）事件循环时间、低抖动和高数据吞吐量。\n[0011] 由用于上面确定的数据传输的方法来解决此目的，其中，数据传输的架构被分成\n对配置、校准和/或诊断（CD）数据进行操作的以软件实现的控制平面和传输测量（M）数据\n和/或原型（RP）数据的以硬件实现的数据平面。\n[0012] 本发明提出一种部件，其实现用于嵌入式ECU接口模块中的基于硬件的多层协议\n处理和基于硬件的QoS的新范例。此新架构方法与当前技术相比提供了至少十倍的性能增\n加。\n[0013] 本发明提出了一种新技术，其使用新架构视图。根据汽车协议的多服务性质，架构\n被分成优选地对使用事务（T）所传输的配置、校准和诊断（CD）数据进行操作的以软件实现\n的控制平面和优选地使用无状态数据流（S）所传输的传输测量（M）和原型（RP）数据的以硬\n件实现的数据平面。\n[0014] 以硬件的数据平面的实现方式相对于现有技术而言具有若干个主要优点，其包\n括：\n[0015] •用于具有低达360ns、在某些情况下甚至低达200ns（现有技术软件方法：> 50µs）\n的事件循环时间的非常快速的事件处理的最优化数据平面。\n[0016] •用于小于2µs（现有技术软件方法：几十µs）的非常低的抖动的最优化数据平面。\n[0017] •用于高达2.8 Gbit/s、在某些情况下甚至高达5.0 Gbit/s（现有技术软件方法：< \n100 Mbit/s）的高数据吞吐量的最优化数据平面。\n[0018] 例如通过ASIC开发而不是FPGA开发，能够实现特别有效的最优化。\n[0019] 根据本发明，以下术语具有随后定义的意义：\n[0020] 接收＝来自外部线路的数据的接收，\n[0021] 传输＝外部线路上的传输，\n[0022] 转发＝将数据从设备转发至数据处理器核并进一步转发到设备。\n[0023] 因此，该序列始终是：接收＝>转发＝>传输。\n[0024] 根据优选实施例，要转发的数据或者数据流在数据转发之前在接收设备侧被分段\n成多个数据段。此外，可能的是，数据段在数据转发之前被交织。最后，如果各种接收设备的\n数据段在数据转发之前被复用，则是有利的。可以在交织过程之前或之后替换地或除交织\n之外实现复用。然后，数据段被顺序转发。如果不止一个设备想要转发数据，则根据交织和/\n或复用过程的结果，数据转发在来自第一设备的数据段与来自另一设备的数据段之间被切\n换。在数据段的转发之后，传输设备将数据段收集到外出设备的接口或线路的数据单元中。\n因此，微观地看（< 1 µs），数据或者数据段分别被顺序转发。然而，宏观地看（> 10 µs），数\n据转发是并行（或者说分别准并行）实现的，因为来自第一设备的数据段与来自另一设备的\n数据段之间的数据转发的切换是非常快速地执行的。这仅因为数据平面是以硬件实现的而\n是可能的，其允许快速的情境切换。情境切换包括存储和恢复处理单元的状态（情境），使得\n能够在稍后的时间从相同的点重新开始执行。这使得多个过程能够共享单个处理。情境切\n换是多重任务操作系统的本质特征。\n[0025] 与此相反，在现有技术软件架构中，来自第一设备的数据段与来自另一设备的数\n据段之间的数据转发的切换被慢得多地执行。这是由于这样的事实，即软件架构中的切换\n包括保存寄存器、存储当前情境、释放用于新情境的CPU等的多个步骤。如果以软件来实现，\n则情境切换花费比在以硬件实现时所花费的长得多的时间。对于其而言的一个原因是基于\n软件的情境切换消耗用于每个软件中断的大量时间。\n[0026] 根据本发明的基于硬件的数据平面实现方式和ECU接口模块的运行分别能够与用\n于加速ECU和/或测量设备之间的数据传输的协处理器相比较。常规协处理器在处理数据方\n面支持CPU。本发明相对于常规协处理器的差别是这样的事实，即将由协处理器处理的所有\n数据在其在协处理器中被处理之前首先通过处理单元。这分别在根据本发明的基于硬件的\n数据平面实现方式和ECU接口模块中是不同的。根据本发明，要传输的所有数据分别地穿过\n基于硬件的数据平面实现方式和ECU接口模块。由此，ECU及其CPU分别显著地从为了数据转\n发而操纵和处理数据中得到缓解。\n[0027] 优选地，数据平面向和从ECU和/或测量设备切换事务和/或流的命令和响应。然\n而，要注意的是—与例如PCI Express切换相反—数据平面的切换并不是事务感知的。在\nPCI Express切换中，切换单元记住命令的路径并沿着相反的方向将此知识用于响应。根据\n本发明，必须预先配置两个路径。\n[0028] 本发明优选被用在机动车辆领域中。其能够被实现为位于第一ECU和第二ECU或被\n连接到第一ECU的测量设备之间的ECU接口模块。此外，其可以在测量设备中被实现，该测量\n设备能够被连接到机动车辆的一个或多个ECU，以便监视和/或控制其操作和运行。此外，可\n以在ECU的网关控制单元中实现本发明。换言之，还可以在ECU本身中实现本发明。\n附图说明\n[0029] 在下文中参考本发明的优选实施例和附图来详细地解释本发明的进一步特征和\n优点。要认识到的是，本发明不一定必须包括下文参考优选实施例描述的所有特征，而是也\n可以仅仅单独地或以与所选其他特征的任何组合地具有所提到特征中的一些。附图示出\n了：\n[0030] 图1现有技术中已知的MCD和原型系统的客户端-服务器实现方式视图，\n[0031] 图2根据本发明的优选实施例的MCD和原型系统的控制和数据平面实现方式视图，\n[0032] 图3根据本发明的另一优选实施例的MCD和原型系统的控制和数据平面实现方式\n视图，\n[0033] 图4根据本发明的实现方式的数据平面（＝数据处理器）管线架构，\n[0034] 图5根据本发明的实现方式的数据处理器信息模型，\n[0035] 图6根据本发明的实现方式的TCP架构上的上行链路XCP，以及\n[0036] 图7根据本发明的实现方式的TCP（高吞吐量）和上行链路原型RTIO（低等待时间）\n上的上行链路XCP。\n具体实施方式\n[0037] 从现有技术已知的汽车协议标准和对应的参考图是以软件驱动的客户端-服务器\n模式为基础的，其示例在图1中被示出。例如在托管测量、校准和诊断（MCD）应用软件或原型\n软件的强大标准个人计算机上运行的客户端充当智能协议主机，以及嵌入式ECU接口模块\n中的服务器充当命令执行协议从机。\n[0038] 服务器中仅链路层是使用标准控制器硬件（CAN控制器、Flexray控制器、以太网媒\n体接入控制器或类似控制器）所实现的。类似于网络层、传输层和汽车协议服务层的较高协\n议层全部是以运行在具有类似于直接存储器存取（DMA）的一些标准硬件支持的实时操作系\n统的顶部上的软件所实现的。\n[0039] 在非常有限的一组中央处理单元（CPU）内的不同链路层的顶部上实现多个协议层\n堆栈要求了使用由底层操作系统所提供的服务和软件线程方法来对与异步输入数据事件\n（帧）相关联的处理进行串行化。\n[0040] 然而，与软件线程相关联的串行化和情境切换开销限制了最大事件率。此事件率\n限制似乎是对于所有基于软件的实时系统的主要瓶颈。其导致用于原型应用的增加的IO等\n待时间和抖动、用于事务的增加的往返时间和由于得到的网络帧速率限制而引起的有限测\n量吞吐量。性能优化是困难的，如果不是甚至不可能实现的话，因为用于减少情境切换开销\n的事件率的抑制使原型和控制平面的低等待时间要求恶化。使用多核CPU技术以便增加软\n件处理能力使ECU接口模块功率消耗要求恶化且不能有效地促进单个高比特率数据会话\n（例如单个TCP连接），因为会话的分组排序禁止对其分组的并行处理。\n[0041] 与此相反，本发明提出了一种使用不同架构视图的新技术。根据汽车协议的多服\n务性质，架构被分成对使用事务（T）所传输的配置、校准和诊断（CD）数据进行操作的以软件\n实现的控制平面和传输测量（M）和原型数据（RP）无状态数据流（S）的以硬件实现的数据平\n面。相应的控制和数据平面实现视图在图2中被示出。\n[0042] 主机（客户端）与从机（服务器）之间的事务还可以分成无状态数据流：载送命令的\n下行链路流和载送响应和事件的上行链路流。由于此事务分割，控制平面对于数据平面而\n言表现为用于上行链路业务量的普通输入设备和用于下行链路业务量的普通输出设备。数\n据平面向和从负责期望物理端口的设备（ECU信宿（sink）、ECU源）切换这些事务流。将下行\n链路和上行链路流关联的事务状态本身位于控制平面中。\n[0043] 如图2中所示，例如传输控制协议（TCP）的有状态协议层，以与有状态汽车协议事\n务层相同的方式在对于数据平面核心而言表现为卫星功能（普通设备）的功能块中被终止。\n协议的状态位于卫星功能中。在由同一申请人提交的另一专利申请（申请号EP 12 188 \n660）中详细地描述了图2中的指定为“传输协议（快速路径）”的功能块。该申请的内容通过\n引用被结合在本文中。例如用户数据报协议（UDP）的无状态协议层在数据平面和网络接口\n内部被终止。\n[0044] 图2中所示的另一卫星功能是快速路径信号处理功能，其包含原型模型并能够根\n据特定使用情况而以硬件或软件来实现。图3示出了包括用于其他卫星功能的示例的MCD和\n原型系统的控制和数据平面实现视图。这些其他卫星功能可以包括例如ISO传输协议功能、\n安全（加密）功能和/或信号水平网关功能。\n[0045] 公共数据平面的主要优点是这样的事实，即能够观察所有输入业务量，该所有输\n入业务量对于控制等待时间、抖动、吞吐量等方面的服务质量（QoS）而言是必不可少的。\n[0046] 由本发明提出的控制平面和数据平面的分离能够实现优化的实现方式。通过ASIC\n开发而不是FPGA开发能够实现进一步的优化。\n[0047] ▪数据平面完全是以硬件实现的，并且针对具有低达200ns（当前软件方法：> 50 µ\ns）的事件循环时间的非常快速的事件处理而被优化。\n[0048] ▪数据平面完全是以硬件实现的，并且针对小于2 µs（当前软件方法：几十µs）的非\n常低的抖动而被优化。\n[0049] ▪数据平面完全是以硬件实现的，并且针对高达5 Gbit/s（当前软件方法：< 100 \nMbit/s）的高数据吞吐量而被优化。\n[0050] ▪在不违反嵌入式ECU接口设备的功率消耗限制的情况下，在同一硬件内全部三个\n优化（事件循环时间、抖动、数据吞吐量）是可能的。\n[0051] ▪控制平面是以软件实现的，并且针对内容感知、有状态事务处理而被优化。由于\n从协议层中的快速事件处理下载软件，所以可用CPU性能能够被更有效地使用。\n[0052] ▪类似于TCP或IP分片的有状态传输协议是以针对性能而被优化的硬件（快速路\n径）和（同时存在）以针对特征（层7协议、连接的数目）而被优化的软件（慢速路径）实现的。\n[0053] ▪信号处理可以位于强大的外部模拟节点中，该节点还从细粒度传输事件处理被\n释放并被允许集中于其信号处理功能。\n[0054] 数据平面从输入设备接收数据载送事件，在没有任何情境切换开销的情况下非常\n快速地使这些事件串行化，执行一组泛化处理步骤并将数据载送事件分发到输出设备。\n[0055] 数据事件的服务质量（QoS）感知排队和调度仅在数据平面内执行，这允许了用于\n对于数据吞吐量而言的事务往返时间、等待时间、抖动和公平性的业务量优先级的好得多\n的控制。\n[0056] 设备同时地操作并输送事件，同时数据平面核心或数据处理器利用如图4中所示\n的内置合作硬件多线程遵循严格的管线方法顺序地处理事件。根据图4中所示的优选实施\n例，数据平面由以下基本部件组成：\n[0057] 数据平面设备\n[0058] 设备同时地操作，封装物理和链路层特定行为或有状态协议功能并向数据平面核\n心管线提供串行化支持。\n[0059] 数据平面核心管线＝数据处理器\n[0060] 基于通用信息模型来执行实际事件处理：\n[0061] 分类、重新组装、排队、分级调度、分段和报头修改。\n[0062] 管线由一组连锁的良好定义的处理阶段（JF、CL、IM、SW、MC、EQ、LL、DQ、SR、EM、IF）\n组成。\n[0063] 数据处理器对数据的描述符（指针）而不是数据本身进行操作，这节省了逻辑门和\n功率。\n[0064] 描述符库\n[0065] 描述符库是到位于本地或远程存储装置中的数据缓冲器的索引的储存库。\n[0066] 数据存储装置\n[0067] 存在两个数据存储装置类型：\n[0068] ▪位于ECU接口模块内的一个本地数据存储装置，以及\n[0069] ▪位于ECU接口模块外部且经由PCI Express或任何其他适当接口可到达的一个或\n多个远程数据存储装置。\n[0070] 设备以固定最大尺寸、例如128字节的数据段的形式来输送数据。该尺寸由去往和\n来自数据存储装置的带宽所确定。多个段行成所谓的数据单元，其对应于协议层特定帧格\n式，例如用于通用测量和校准协议（XCP）层的数据传输对象、用于IEEE 802.1链路层的以太\n网帧、来自CAN总线的CAN帧或Flexray帧。\n[0071] 设备具有关于分段的知识且能够标记数据单元的第一和最后数据段。\n[0072] 数据分段是对于数据处理器中的无阻挡数据事件处理的前提，其中，事件被串行\n化且其中将处理分布在多个管线阶段当中。\n[0073] 数据处理器实现方式是基于通用信息模型，类似于图5中所示的模型，其由以下实\n体及其属性组成。使用这些属性来控制下述处理阶段（数据核心管线架构）。因此，管线能够\n被配置为配准地存储以下实体中的一个或多个，以便映射特定应用。实体可以是静态的（由\n实现方式所定义的多重性）或动态的（由在配置期间来自共享库的分配所定义的多重性）。\n下面列出了最重要的信息模型实体：\n[0074] 设备（静态）\n[0075] 设备是数据段的同时工作的产生者和消费者。每个数据段与设备索引、信道索引\n和/或指示数据段是数据单元的第一、中间还是最后数据段的第一/最后标签相关联。\n[0076] 接收信道（rx信道，动态）\n[0077] 接收信道是在设备范围内的独立逻辑输入数据信道。设备可以具有多个接收信\n道。接收信道被用来从在时间上被交织的数据段重新组装数据单元。\n[0078] 流（动态）\n[0079] 流是相对于特定协议层的数据会话的描述。其被用来控制数据处理器中的数据处\n理操作，例如协议特定报头到输出有效载荷数据流中的插入。流被附着于接收信道。\n[0080] 队列（动态）\n[0081] 队列存储数据的描述符。存在三个基本类型的队列：尾降队列、三元组缓冲器和优\n先级列表。尾降队列被用来控制服务质量（QoS），例如业务量优先级和公平性。三元组缓冲\n器在原型实时10（RTIO）功能中被用来为信号处理提供最新输入数据的一致样本。优先级列\n表被用在具有基于严格优先级的仲裁的总线系统（类似于CAN总线）上。队列的辅助任务是\n从输入数据段重新组装数据单元。\n[0082] 传输优先级信道（静态或动态）\n[0083] 传输优先级信道表示在外出方向上的独立数据信道。每个传输优先级信道表示在\n其关联的输出设备的范围内的严格优先级调度水平。传输优先级信道本身与一个或多个队\n列相关联，其以加权循环方式被调度。\n[0084] 传输优先级信道可以调度数据段（在每个段之后改变被调度的队列）或数据单元\n（一旦运行中的数据单元已经被完全调度，则改变被调度的队列）。\n[0085] 通过调度数据段多次但以较低字节计数并向数据缓冲器中提供附加偏移，传输优\n先级信道可以改变分段粒度。\n[0086] 信道互通功能（动态）\n[0087] 信道互通功能是可选实体，并被用来提供用于分布在多个顺序数据段当中的业务\n流的进入和外出路径之间的聚合信息。\n[0088] 调度器（静态）\n[0089] 数据处理器实现3级分级调度：1）设备的加权循环调度，2）设备内的传输优先级信\n道的严格优先级调度，以及3）传输优先级信道的范围内的队列的加权循环调度。\n[0090] 数据核心管线由如下所述的通用处理阶段组成。数据核心管线架构在图4中被示\n出。处理步骤对应于上述的通用信息模型（数据处理器实现方式）。\n[0091] 输入接口—IF\n[0092] 输入接口将设备连接到数据平面核心并使用在被连接的设备间进行的加权循环\n调度来使同时输入的数据事件串行化。\n[0093] 与事件相关联的数据能够“按值”被传递，这是默认的，或者“按引用”被传递。在后\n一种情况下，数据处理器假设与事件相关联的数据有效载荷已被存储，并且仅接收到对数\n据有效载荷的缓冲器索引。下述的示例图示出对TCP使用情况的在XCP的情境中的按索引的\n切换。这也是由同一申请人提交的另一专利申请（申请号EP 12 188 660）的主题。此申请通\n过引用被结合在本文中。\n[0094] 分类器—CL\n[0095] 分类器使用描述符以及第一有效载荷数据来通过从以上信息构建秘钥并产生包\n含以下信息的结果向量来将数据段分类：\n[0096] 库索引、队列索引、下降标签、流ID、互通功能索引等。此信息被输入到描述符中。\n[0097] 进入修改器—IM\n[0098] 进入修改器提供了用以通过改变数据本身或通过操纵描述符来修改（扩展或减\n少）输入数据的手段。\n[0099] 段写入器—SW\n[0100] 段写入器按照库分类器所命令的从库分配描述符，并使用描述符的缓冲器索引来\n将有效载荷数据写入到其目的地。\n[0101] 多播—MC\n[0102] 多播阶段提供用于朝着多个目的地分发数据的手段。其维护多播表，该多播表由\n包含在所接收的描述符中的多播组标识符所寻址并输送队列的列表。所接收的描述符在多\n播阶段内被克隆以被排队到多个输出队列中。描述符接收参考计数以便管理缓冲器库。\n[0103] 排队引擎—EQ\n[0104] 排队引擎执行将描述符存储到所选队列中并使得队列对于调度器可见所需的所\n有操作。\n[0105] 链接列表控制—LL\n[0106] 链接列表控制维护表示数据队列的描述符的链接列表。其从排队引擎接收排队命\n令并从调度器或解队引擎接收解队命令。\n[0107] 解队引擎—DQ\n[0108] 解队引擎是调度执行单元。其以每输出设备的传输优先级信道形式使用设备的输\n出FIFO状态和已配置优先级信息来确定要被维护的下一队列。其还能够通过将运行中的数\n据段分成较小数据段来将业务量重新分段，或者通过在维护用于当前传输优先级信道的另\n一队列之前调度数据单元的所有数据段来保持数据单元一致性。\n[0109] 段读取器—SR\n[0110] 段读取器使用包含在描述符中的缓冲器索引来从本地或远程数据存储装置读取\n数据。\n[0111] 外出修改器—EM\n[0112] 外出修改器使用来自描述符的流ID及其他标签来根据其配置修改有效载荷数据\n流，例如通过向或从数据流添加或去除数据或者通过操纵描述符内容。\n[0113] 输出接口—OF\n[0114] 输出接口将数据段分发到已经宣布其准备好接收更多数据（输出FIFO未满）的那\n些输出设备。使用具有与期望线速率成比例的权重的加权循环算法来维护设备。\n[0115] 本地库—LP\n[0116] 本地库包含到本地数据存储装置中的缓冲器的软件准备索引。那些缓冲器索引是\n描述符的核心属性。\n[0117] 远程库—RP\n[0118] 远程库包含到远程数据存储装置中的缓冲器的软件准备索引。可以存在用于多个\n远程数据存储装置的多个远程库。\n[0119] 管线和设备ETHIP、TCPS、TCPR、CPU_L、TEA之间的接口关于其语法是相同的，但是\n关于其语义是协议特定的。\n[0120] 下面，以示例性基础描述本发明的两个实施例。图6中所示的第一实施例参考使用\nTCP上XCP（上行链路）的基于双路径透明ECU访问（TEA）的ECU测量。本实施例使用面对ECU的\nTEA设备。TEA设备终止XCP流送服务层（S）并输送包含加时间戳的测量数据的XCP标准数据\n传输对象（DTO）。本地CPU终止XCP协议事务服务层（T）并输送标准XCP控制传输对象（CTO）。\n[0121] 在PATH 1中，数据处理器将CTO和DTO复用并终止XCP协议的传输层，该XCP协议的\n传输层包含对于CTO和DTO而言公共的XCP分组计数器。\n[0122] 有状态TCP协议层在TCP发送器（TCPS）设备中被终止，该TCP发送器（TCPS）设备与\n向TCP发送器输送确认的TCP接收机（TCPR）设备协作。\n[0123] 在PATH 2中，数据处理器将来自本地CPU的软件堆栈的TCP段和以太网帧朝着公共\nIP网络和以太网链路层进行复用。\n[0124] ETHIP设备最后终止IP网络层和以太网链路层。\n[0125] 要注意的是，下行链路TCP会话与上行链路会话共存，并且也经过数据处理器两\n次。因此，对于TCP会话上的全XCP而言，在数据处理管线内部存在四个共存路径。\n[0126] 图7中所示的第二实施例参考用于外部模拟节点的基于单路径TEA（ETK）的实时IO\n（RTIO）。本实施例向第一实施例的前一方案添加了低等待时间原型RTIO路径。RTIO终止发\n生在数据处理器内部的PATH 1期间。PATH 2未被用于RTIO。\n[0127] TEA设备使用用于RTIO的专用接收信道来输送DTO。由于信号处理单元（模拟节点）\n是远程实例（设备CPU-R），所以数据处理器将来自载送缓冲器索引的远程库的描述符分配\n到模拟节点的远程数据存储装置中，并将数据早先推入远程存储器中。\n[0128] 数据处理器队列作为三元组缓冲器进行操作，其将被分成数据段的来自数据传输\n对象的信号组重新组装。一旦信号组样本是完整的，则向模拟节点声明中断，该模拟节点然\n后从三元组缓冲器读取地址信息。相应的数据已经到达，并且甚至可能在模拟节点的高速\n缓冲存储器中已经可用。\n[0129] 下文列出了本发明的关键特征和关键思想中的一些和与之关联的优点中的一些\n的示例性选择：\n[0130] •关于数据和控制的正交视图\n[0131] ○关于数据平面的数据流视图和关于控制平面的客户端服务器视图\n[0132] ○控制平面是数据平面的普通客户端\n[0133] ○数据平面提供用于控制平面的QoS\n[0134] •设备泛化\n[0135] ○到数据处理器的泛化设备接口\n[0136] ○设备特定功能的封装\n[0137] ○物理设备\n[0138] ▪封装链路层特定控制器\n[0139] ▪示例：CAN、FlexRay、Ethernet、TEA（ETK）\n[0140] ○软件设备\n[0141] ▪封装软件功能\n[0142] ▪示例：本地CPU（本地软件）、远程CPU（远程软件）\n[0143] ○协议设备\n[0144] ▪封装有状态协议功能\n[0145] ▪示例：TCP\n[0146] ○信号处理设备\n[0147] ▪封装信号处理实例\n[0148] ▪示例：CPU模块、外部PC、基于硬件的信号处理实体\n[0149] •多用途排队\n[0150] ○用同一硬件满足多个要求\n[0151] ▪用于高吞吐量测量和控制平面的尾降队列\n[0152] ▪用于低等待时间原型的头降缓冲器（三元组缓冲器）\n[0153] ▪服务质量（QoS）\n[0154] ▪数据单元重新组装\n[0155] •多路径操作\n[0156] ○在同一硬件上启用多层操作\n[0157] ○使用描述符扩展的客户端层隧通\n[0158] ○示例：以太网上的XCP；path 1：XCP；path 2：IP/以太网\n[0159] •基于描述符的数据处理\n[0160] ○最小化数量存储器访问\n[0161] ○减少逻辑触发率和功率消耗\n[0162] ○减少接口触发率\n[0163] ▪接口模式“按值”和“按索引”（仅长描述）\n[0164] •数据分段\n[0165] ○最大化输入事件率（串行化率）\n[0166] ○减小设备缓冲器尺寸\n[0167] ○最小化抖动和等待时间\n[0168] •管线架构\n[0169] ○消除情境切换开销\n[0170] ○增加确定性\n[0171] ○通过合作多重任务来简化实现方式\n[0172] •泛化数据存储处理\n[0173] ○本地库和远程库\n[0174] ○本地存储器和远程存储器\n[0175] •通用信息模型\n[0176] ○通过控制逻辑和算法重新使用来减少逻辑的努力和量\n[0177] ○按配置而不是实现方式的协议实现方式\n[0178] •基于队列的多播\n[0179] ○多客户端支持\n[0180] •用于ECU接口的空间多播\n[0181] ○具有相反QoS要求的会话的逻辑分离\n[0182] • 3级分级调度\n[0183] ○经由严格的优先级调度来保证低等待时间\n[0184] ○经由加权循环调度来保证公平性。