CN118871887A - 用于在车辆的通信系统中转发数据的方法 - Google Patents

Abstract

本发明涉及用于在车辆的通信系统(11)中转发数据的方法，其中，所述通信系统(11)包括至少一个第一总线系统(10，12，14)和至少一个另外的总线系统(10，12，14)，其中，数据能够在所述总线系统(10，12，14)之间被交换，与作为独立的实施实例的至少一个第一域(40，42，44)，尤其是AUTOSAR域(40，42，44)进行交换，其中，在所述第一域(40，42，44)中能够实施应用程序(46，48)、尤其是车辆功能，其中，所述第一域(40，42，44)包括到所述应用程序(46，48)的、至少标准化的接口，尤其是AUTOSAR实时环境，其中，通过作为与所述第一域(40，42，44)独立的另外的实施实例的另外的域(16，18，20)进行在所述通信系统(11)和所述第一域(40)之间的数据的交换，其方式是，仅仅通过所述另外的域(16，18，20)访问所述通信系统(11)的物理的接口(13)，其中，至少在转发方面处理通过所述通信系统(11)的物理的接口(13)在所述另外的域(16，18，20)中所接收到的数据(70，72，74)。

Description

用于在车辆的通信系统中转发数据的方法

技术领域

本发明涉及一种根据独立权利要求的类型的、用于在车辆的通信系统中转发数据的方法。

背景技术

用AUTOSAR(汽车开放系统架构)表示来自汽车制造商、控制设备制造商以及开发工具、控制设备基本软件和微控制器的制造商的开发合作伙伴关系，所述开发合作伙伴关系的目标在于，使在不同的控制设备上的软件的交换变容易。

AUTOSAR提供一组规范，所述规范描述基本的软件模块，定义应用程序接口，并且基于标准化的交换格式创建一种共同的开发方法。由AUTOSAR分层软件架构提供用于使用的基本软件模块可以被使用在不同的制造商的车辆和不同的供应商的电子部件中。

从US 8966443中已知一种绕开AUTOSAR软件系统的AUTOSAR软件部件的方法。

本发明的任务在于，进一步改进处理速度、尤其是AUTOSAR软件系统的处理速度。该任务通过独立权利要求的特征解决。

发明内容

根据独立权利要求的特征的方法正是针对具有集成的网关功能的控制设备实现对特定的数据的高性能的转发或者路由。通过将路由功能相应地外包给另外的域，可以减轻第一域、尤其是AUTOSAR域的负担。这导致在整体系统中更好的负载平衡和尤其是在使用多核控制器时对硬件资源的更好地利用。由于所提出的、呈不同的域和任务分布形式的混合的软件架构，一方面，在AUTOSAR域中的软件可以保持不变以便实现车辆功能的托管(Hostings)，而在另外的域上的软件可以恰好在数据转发的性能方面和因此针对性能相关的应用情形进行优化。由于所提出的、功能在不同的域中和因此在不同的实施实例中的分布，它们可以根据系统要求和设计而灵活地分布在一个或者多个CPU内核上。尤其是在车辆的行驶运行中，由于所提出的解决方案可以实现低的路由延迟。此外，由此实现：与第一域的数据交换总是通过另外的域进行，所述另外的域的突出之处在于性能强大的转发机制。特别符合目的地，与高性能相关的数据保留在另外的域中以供进一步处理，而另外的数据被转发到第一域。

在一种符合目的的拓展方案中，针对第一总线系统使用自身的另外的域，并且针对另一个总线系统使用另外的自身的域，其中，这两个另外的域之间的数据交换仅仅在数据单元的层级上进行，尤其是在协议数据单元(PDU)、尤其是通用的数据单元和/或被包含在容器中的数据单元的层级上进行。正是这些路由机制被广泛地应用到这样的应用数据上：当车辆在正常运行中行驶时，所述应用数据在不同的控制设备上的车辆功能之间交换。

在一种符合目的的拓展方案中，设置，在第一和另外的域之间，数据可以在帧的层级上和/或在数据单元的层级上、尤其是通过使用两个域共有的存储器交换，而在另外的域中的一个域与另外的域中的一个不同的域之间，数据仅仅在数据单元的层级上、然而不在帧的层级上交换。因此，可以动用与功能和协议无关的数据交换机制。由此可以实现，可以维护在AUTOSAR标准中所定义的接口，从而简化第一域在整体系统中的集成或者可以如通常这样地维护。基于数据单元在另外的域内部的数据交换可以特别快速地和高性能地执行。

在一种符合目的的拓展方案中，设置，另外的域包括至少一个驱动器，其用于连接在通信系统、尤其是总线系统的物理的接口上，尤其是用于数据访问或者用于ISO/OSI第2层的控制机制，和/或另外的域包括至少一个协议存储器或者协议栈(Protokoll Stack)，其尤其用于数据访问或者用于ISO/OSI第3-5层的控制机制，所述控制机制对于处理来自另外的域的与高性能相关的数据是必需的，和/或另外的域包括至少一个网关，其用于至少一个数据单元的转发、尤其是在不同的另外的域的协议栈之间转发。一方面，由此确保仅仅通过另外的域进行通信。此外，可以进行对性能相关的应用情形的高性能的处理，如例如处理非传输协议以便提取用于高性能路由的数据单元。

在一种符合目的的拓展方案中，设置，在第一域、尤其是AUTOSAR域中，设置一种虚拟的驱动器，尤其是作为真实的驱动器的代理，其用于在第一域和另外的域之间与另外的域的相应的驱动器交换帧，和/或用于与设置在第一域中的、用于帧的接口交换，和/或在第一域中设置至少一个适配器，以便与另外的域的网关交换数据或者数据单元和/或用于与设置在第一域中的、用于数据单元的路由器交换。由此确保，对物理的通信接口的直接的访问被局限于另外的域上。然而，可以通过虚拟的接口考虑将另外的域相应地包含在尤其是AUTOSAR架构定义中。通过适配器，可以在数据单元的层级上确保与另外的域的数据交换。

在一种符合目的的拓展方案中，设置，从对第一域的系统说明、尤其是完整的AUTOSAR控制设备提取(AUTOSAR--Extrakt)中生成与数据在另外的域中的转发有关的配置代码和/或对第一域的缩减的系统说明、尤其是缩减的AUTOSAR控制设备提取。因此，可以调整现有的工具链，以便从完整的控制设备配置中得出相应的域专用的配置。由此，可以进行针对两个域的自动化的软件生成。这涉及一种用于处理尤其是AUTOSAR标准输入(以ARXML格式的控制设备提取)的工具支持，不但用于配置AUTOSAR域的软件而且用于配置另外的域的软件。

在一种符合目的的拓展方案中，通过使用描述数据转发的数据模型来产生配置代码。通过数据模型可以进行用于另外的域的从控制设备提取中所提取的路由装置的数据的存储和可视化。

从另外的从属权利要求和从说明书得出另外的符合目的的拓展方案。

附图说明

附图示出：

图1示出机动车的经典的E/E架构，

图2示出机动车的域E/E架构，

图3示出机动车的中央的E/E架构，

图4示出混合的软件架构的抽象的表示，

图5示出数据结构的示意性的示图，

图6示出在混合的软件架构中的不同的数据路径，

图7示出在另外的域中的一个以内用于PDU和容器的路由的数据路径，

图8示出在与接收部分相关的另外的域中的两个之间用于PDU和容器的路由的数据路径，

图9示出在与传输部分相关的另外的域中的两个之间用于PDU和容器的路由的数据路径，

图10示出用于由AUTOSAR域接收和传输帧的数据路径，

图11示出用于由AUTOSAR域接收和传输PDU的数据路径，

图12示出用于通过应用和PDU路由进行PDU接收的数据路径，

图13示出用于混合的软件架构的工具和工作流程，以及

图14示出路由设置的数据模型。

具体实施方式

根据一个实施例示意性地示出并且随后参照绘图详尽地说明本发明。

在汽车语境下，车辆的电气和电子架构(E/E)包括通过通信信道相互连接的电子控制设备5的网络。这些E/E架构这样设计，使得在控制设备5之间的信息交换被限制。信息的这种限制在技术上通过网关功能3进行，所述网关功能作为纯软件解决方案或者软件硬件解决方案集成在车辆中的通信接口上的特定的控制设备2，4，6，7，8中。网关3的任务在于，将相同的或者不同的车辆总线技术(例如CAN，LIN，Flexray，以太网或者类似物)的通信信道相互连接起来并且实现在它们之间的通信消息的受控的传输。在图1-3中示出不同的E/E架构。

根据图1的经典的E/E架构的特征在于具有网关功能3的中央网关2，通过所述网关功能3使多个通信信道相互连接，控制设备5分别连接在所述多个通信信道上。控制设备5的子组可以用数据技术通过又具有网关功能3的子网关4相互连接。

在根据图2的域相关的E/E架构中，又设置有中央网关2，所述中央网关将多个域控制设备6(其具有包含在其中的网关功能3)相互连接起来用于数据交换的目的。通过域控制设备6，可以设置另外的控制设备5或者可以根据架构设置子网关4(其具有连接在其上的控制设备5)，用于数据交换的目的。

在根据图3的区域相关的E/E架构中，设置多个具有网关功能3的区域控制设备9，所述区域控制设备可以例如布置在机动车中的不同的位置上。区域控制设备9通过计算装置8、尤其是性能强大的车辆计算机8相互连接，用于数据交换的目的。为此，计算装置8同样地包括网关功能3。通过区域控制设备9用数据技术将另外的控制设备5连接起来，所述另外的控制设备在空间上(例如在车辆中在左前方、在右前方、在车尾侧等等)布置在该区域的范围内。根据应用情况，也可以设置用于连接另外的控制设备5的子网关4。

大多数控制设备5的主要应用情形是，托管应用软件部件用于实现不同的车辆功能(例如制动器、发动机控制、能量管理等等)。为了使其变容易，在AUTOSAR中为软件架构定义汽车标准。AUTOSAR定义在实时环境(也称为RTE，Real-time-environment)中应用软件部件的标准接口和如运行系统、通信、诊断、在基本软件中的非易失性的数据存储等等这样的相应的基础设施的机制。因此，有利的是，保留用于该应用情形的、具有标准软件AUTOSAR的标准化的方法。

然而，对于具有集成的网关功能3的控制设备，必须满足如通信消息等等的高性能地转发这样的性能强大的数据处理。尽管必需的路由功能由AUTOSAR标准定义和支持，但是在AUTOSAR标准软件中的路由性能通常不足以满足如其例如由车辆制造商定义的性能要求。由于由AUTOSAR对软件架构、功能和接口的标准化和在标准软件改变时的责任问题，因此在性能方面优化软件的可能性受到限制。此外，车辆制造商的不同的通信范式和路由机制通过车辆制造商专用的解决方案提供附加的优化潜力，所述解决方案不能与AUTOSAR标准软件一起被使用。因此，AUTOSAR标准软件对于网关功能3的实现不是最优的。

在随后的实施例中，更详尽地说明了网关功能3，所述网关功能实现用于AUTOSAR环境的性能强大的数据处理或者数据路由。对于不但必须满足应用情形(托管车辆功能)并且必须满足网关功能3的控制设备5，提出一种性能卓越的软件架构和完整的软件解决方案。这被称为具有集成的网关功能3的汽车控制器的混合多核(Multi-Kern)软件架构。

混合的软件架构被分为独立的实施实例，以下被称为域16，18，20；40，42，44。这些域16，18，20；40，42，44可相互独立地实施，并且特征在于不同的分区，尤其是软件分区。在不同的域16，18，20；40，42，44之间的通信或者通过相应的接口或者例如通过特定的存储设计(共享内存：例如环式缓冲区，不同的域16，18，20；40，42，44可以根据特定的规则(写入/读取；存储区域等等)访问所述环式缓冲区)用于数据交换的目的)进行。在多核CPU系统(微控制器或者微处理器或者片上系统SOC)中，这些域可以根据控制设备系统要求和设计灵活地分布在一个或者多个CPU内核上。通用的数据交换机制(作为在至少第一域40，42，44、尤其是AUTOSAR域和另外的域16，18，20、尤其是通信域之间的域间通信30，66)实现在域16，18，20；40，42，44和内核之间的数据交换或者在计算机内核以内的数据交换。

采用将软件架构附加地分区为独立的实施单元(以下称为所谓的域16，18，20；40，42，44)。这些域16，18，20；40，42，44具有相应的实施功能，所述实施功能可以灵活地作为周期性的任务(Aufgaben或Task)或者中断纳入到运行系统规划中，以便实现必需的控制设备系统行为。

AUTOSAR架构的一部分被分派给至少一个(第一)域40，42，44或者根据应用情形也被分派给多个(第一)域40，42，44，所述至少一个(第一)域以下被称为第一或者AUTOSAR域40，42，44并且所述至少一个(第一)域完全符合AUTOSAR标准并且不会发生任何变化。该AUTOSAR域40，42，44可以实现为AUTOSAR单核架构或者多核架构。在AUTOSAR域40，42，44中，根据应用情形，可以设置不同的应用程序46，示例性地表示为车辆功能程序48.1，48.2，…，48.n。此外，相应的AUTOSAR域40，42，44包括基本软件52，所述基本软件可以包括例如路由器、尤其是PDU路由器54(I-PDU：交互层协议数据单元，由AUTOSAR定义的数据单元，以下也称为PDU(协议数据单元)或者数据单元)和/或用于所使用的总线系统(例如CAN、Flexray、以太网等等)的接口56。

与至少一个(第一)AUTOSAR域40，42，44无关地，设置至少一个另外的域16，18，20，优选地设置多个另外的域16，18，20。另外的域16，18，20具有独立的实施功能，所述实施功能涉及数据的路由和处理。特别优选地，对于(相应的通信系统11的)各种通信协议，设置自身的域16，18，20，例如CAN域20、Flexray域18、以太网域16等等。另外的域16，18，20访问通信系统11的相应的物理的接口13并且处理相应的通信系统11的消息。

在AUTOSAR域40，42，44和另外的域16，18，20之间的功能性的划分(尤其是用于数据的路由)这样进行，使得与高性能相关的应用情形(所述应用情形的突出之处在于数据的快速的路由和转发)被分派给另外的域16，18，20。应由在控制设备中的网关3实现的完整的数据转发的大部分使用所谓的PDU机制和容器路由机制。该路由机制广泛地被应用到应用数据上，当车辆行驶时(正常运行)，所述应用数据在控制设备5上的车辆功能之间交换。这种应用情形对低的路由延迟具有高的要求并且因此被分派给那个或者那些用于路由或者转发数据的另外的域。数据在另外的域16，18，20中的转发与在数据单元PDU 72或者容器74中相结合地进行，尤其是通过在数据头(Header)80中的信息或者如例如保存在路由表格中的转发信息进行。通过数据头80或者其相关联的信息可以实现如下标识：要如何解释或者转发以下的用户数据82。

所有其余的如例如诊断任务或者类似这样的应用情形或者标准情形(所述应用情形或者标准情形的突出之处不在于快速的数据转发)被分派给AUTOSAR域40，42，44。所有剩余的应用情形，如本地终端(Terminierung)(通过所托管的车辆功能进行接收和传输)、传输协议(ISO-TP(国际标准组织-传输协议)、TCP(传输控制协议)、诊断通信和诊断路由(UDS，统一诊断服务)、OBD(车上诊断)、DoIP(互联网协议诊断)、网络管理等等被分派给AUTOSAR域40，42，44。

在混合软件架构中的域16，18，20；40，42，44可以映射到多核CPU系统(微控制器或者微处理器或者片上系统(SoC))中的一个或者多个CPU内核上，以便满足控制设备要求和设计(例如，接口的数量、数据流量(Datenverkehr)、延迟和吞吐量要求、由路由引起的CPU负载等)。

第一或者AUTOSAR域40，42，44可以实现为如其由AUTOSAR标准定义的单核或者多核实现。

对于通信协议而言专用的另外的域16，18，20可以灵活地映射到CPU内核上，以便实现单核或者多核实现。每个另外的域16，18，20可以被分派给其他的CPU内核(例如CAN内核、以太网内核等)或者多个或者所有另外的域16，18，20可以被分派给单个的内核(例如在单个的内核上的CAN，Flexray和以太网)。

在AUTOSAR域40，42，44和另外的域16，18，20之间的通信数据的交换通过通用的数据交换机制进行，所述通用的数据交换机制例如如以上所说明地基于共享内存设计并且被称为域间通信30，66，位于进行通信的第一域和另外的域16，18，20；40，42，44中，如在图4中所表明地。

域间通信30，66是一种与功能和协议无关的数据交换机制，所述数据交换机制实现数据块从一个发送者到一个或者多个接收者的传输。

数据块(例如，根据图5的用户数据82)伴有附加的元信息(例如，根据图5的数据头80)，即例如它们的识别标志和长度，所述附加的元信息使得发射机和接收机能够对所交换的数据共同地进行解释。数据交换的时间规划可以通过轮询(Polling)或者中断模式来配置。所交换的数据可以附加地通过如验证这样的安全机制来保护，以确保数据完整性。

如果根据控制设备设计将区域(数据在所述区域之间被交换)映射到不同的内核上，则相同的数据交换机制被称为内核间通信。

在本应用的框架下，根据图5的数据单元帧70、PDU 72和容器74是相关的。这些数据单元的格式遵循TLW模式(类型、长度、值)。类型(标识符、附加的协议参数)和长度(用户数据82或者有效载荷，以字节为单位)是元信息，所述元信息共同地被称为数据头80并且给出值的内容(用户数据82或者使用者数据)。

框架或者帧70是这样的数据的单元：所述数据被传输到特定的通信协议的物理的接口13上，并且所述数据的准确的格式由协议(CAN、Flexray、以太网)定义。

PDU 72完全地或者部分地相应于框架或者帧70的用户数据82，其包含应用数据(来自具有物理的或者功能上的相关性的信号，例如车辆速度、周围环境温度、故障状态标志等)。PDU 72具有自身的数据头80和有效载荷或者用户数据82。

用于PDU 72的容器74是收集器，所述收集器被使用于，对多个所包含的PDU 72进行编组。在没有容器74的情况下在帧70中被传输的PDU 72被称为通用的PDU 72。容器74、被包含在容器74中的PDU 72和通用的PDU 72具有其相应的数据头80和有效载荷或者用户数据82。这些数据单元可能具有嵌套的结构，在所述嵌套的结构中，帧70由通用的PDU 72和/或容器PDU 72组成，并且容器PDU 72本身由被包含在容器74中的PDU 72组成，如在图5中示例性地示出地。

为了符合在AUTOSAR标准中所定义的接口(API：应用程序编程接口)，可以在数据单元帧70(参看图4，在另外的域16，18，20的通信驱动器24和第一域40，42，44的虚拟的驱动器64之间的下方的双箭头)和PDU 72(通用的和被包含在容器74中的PDU 72；在图4中通过在PDU网关28和PDU适配器60之间的上方的双箭头表明，转发给第一域40，42，44的PDU路由器54)的层级上在另外的域16，18，20和AUTOSAR域40，42，44之间交换数据。

为了与与AUTOSAR域40，42，44交换的数据单元相应，数据可以仅仅在数据单元PDU72(通用的和/或被包含在容器74中的PDU 72)的层级上在另外的域16，18，20之间交换。由于相应的协议的不同的帧布局，基于不同的通信协议(CAN、Flexray、以太网)的两个另外的域16，18，20之间的数据交换在帧的层级上是不可能的。

在混合的软件架构以内，对CAN、Flexray和以太网协议的物理的通信接口13的直接的访问仅仅局限于相应的另外的域16，18，20，所述相应的另外的域与数据的路由或者转发相关。这种方法使得另外的域16，18，20能够直接从接口13接收消息并且在短时间以内将它们断开。消息被保存在相应的另外的域16，18，20中用于进一步处理，并且，其余的消息被转发给AUTOSAR域40，42，44。因此，AUTOSAR域40，42，44不具有对相应的通信系统11的接口13的直接的访问，而是通过相应的另外的域16，18，20间接地接收与其相关的消息。

针对相应的通信协议(CAN、Flexray、以太网)专用地设置的另外的域16，18，20的软件架构类似地构造(见图4)。用于相应的另外的域16，18，20的路由装置22分别由用于连接在通信系统11的相应的物理的接口13上的通信驱动器24、通信协议栈26或者用于处理更高的协议层(例如CAN/FR/ETH…)的堆栈存储器和用于转发PDU 72的、与协议无关的PDU网关28组成。对于与其他的(另外的)域16，18，20或者AUTOSAR域40，42，44的数据交换，域间通信30的实例是必需的。

通信驱动器24实现与ISO/OSI第2层相关的数据访问(读取和写入)和控制机制(模式和故障管理)，这对于相应的通信协议(CAN、Flexray FR、以太网ETH等)的通信控制和物理的接口13的处理是必要的。

通信协议栈26或者通信协议存储器26仅仅实现那些对于在另外的域16，18，20上的路由相关的应用情形的处理而言必要的ISO/OSI第3-5层的数据访问和控制机制。该范围主要包括对非传输协议消息(非ISO-TP，UDP)的处理，以便提取用于高性能的路由的PDU72。

PDU网关28执行PDU 72在不同的数据源和数据沉(Senken)之间的高性能的转发，即，通过域间通信30，本地的通信协议栈26、在不同的另外的域16，18，20和/或AUTOSAR域40，42，44上的通信协议栈26。这种转发由可配置的路由指示调节，所述路由指示也被称为路由表。转发可以根据相应的数据头80进行。

为了与不同的另外的域16，18，20和AUTOSAR域40，42，44交换数据，在另外的域16，18，20中的每个中实施域间通信30的实例。

AUTOSAR是一个独立的和完整的标准架构。为了将专有的路由架构集成到其中，位于第一域40，42，44上的、直接与任意的AUTOSAR标准模块52，54，56连接的软件模块58，60，62，64必须被采用并且被列入控制设备的AUTOSAR架构定义中。AUTOSAR标准提供了使用复杂的设备驱动器58(CDD)用于这样的集成的可能性。

在AUTOSAR标准架构中，通信接口的驱动器(CAN/Flexray/以太网驱动器)是微控制器抽象层(MCAL)架构层的一部分。因为在混合的软件架构以内对物理的通信接口13的直接的访问局限于另外的域16，18，20上，因此必须通过所谓的虚拟的通信驱动器或者用于相应的协议的虚拟的驱动器64(CDD)使MCAL适应于AUTOSAR域40，42，44。顾名思义，虚拟的驱动器64不涉及真实的驱动器，而涉及实际的驱动器的代理，并且相对于所谓的控制设备抽象层(ECU抽象层，ECUAL)的上一级的接口模块(CAN/Flexray/以太网接口)作为标准AUTOSAR-API使用。虚拟的驱动器64与它们的配合件(Gegenstücken)相互作用并且交换帧50，即，通过域间通信30，66与在相应的另外的域16，18，20上的实际的通信驱动器24交换，所述域间通信也作为对应方(Pendant)位于AUTOSAR域40，42，44上。

在AUTOSAR标准架构中，PDU路由器54是软件模块，在所述软件模块中，PDU 72在下方的层和上方的层的不同的软件模块之间被转发。为了可以在AUTOSAR域40，42，44和另外的域16，18，20之间交换PDU 72，被称为PDU适配器60的驱动器CDD(AUTOSAR复杂设备驱动器)作为AUTOSAR PDU路由器54的低级模块被列入架构中。PDU适配器60通过域间通信30，66与相应的另外的域16，18，20的PDU网关28相互作用和交换PDU 72。这通过所提到的共享内存架构(即，如例如环式存储器这样的共有的存储器)实现。

域间通信66的实例在AUTOSAR域40，42，44中实施，以便实现与在另外的域16，18，20上的配合件的数据交换。在AUTOSAR域40，42，44中的帧70和PDU 72的接收和传输通过从或者到(在帧层级上的)虚拟的通信驱动器64或者(在PDU层级上的)PDU适配器60地转发这些数据单元来实现。然而，不同于虚拟的通信驱动器64和PDU适配器60地，域间通信66不可以被列入到AUTOSAR架构定义中，因为它不直接与标准AUTOSAR模块52，54，56连接。

为了给车辆功能和网关应用情形5的托管定址(Adressierung)，在混合的软件架构中沿着不同的数据路径转发和处理来自两个数据源(即，物理的通信接口13和应用软件部件)的数据，如从图6显而易见地。

针对所接收到的框架或者帧70的转发决策90分别位于另外的域16，18，20或者相关联的通信驱动器24中，以便进一步处理直接从相应的接口13(CAN、Flexray、以太网)所接收的帧70。另外的域16，18，20具有与数据的路由相关的独立的实施功能。根据在通信驱动器24内部对用于帧70的数据头80进行分析利用的情况下可配置的转发决策90，将(在步骤88中)所接收到的帧70转发给以下的目的地之一：

-仅仅对于AUTOSAR域40，42，44：仅仅应在AUTOSAR域40，42，44中被进一步处理的帧70仅仅通过相应的虚拟的驱动器64(CDD)转发给AUTOSAR(CAN/Flexray/以太网)接口模块56。

-仅仅对于另外的域16，18，20：具有要被提取和进一步处理的、应用相关的PDU 72的帧70在另外的域16，18，20内部的软件栈26或者通信协议栈26(通信协议栈26和PDU网关28)中仅仅向上转发(给相应的另外的域16，18，20)。

-不但对于AUTOSAR域40，42，44而且对于另外的域16，18，20：对于特定的特殊情况，帧70不但被转发给AUTOSAR域40，42，44，而且向上转发到另外的域16，18，20的软件栈或者通信协议栈26中。

用于所接收到的框架或者帧的转发决策90可以如下地概括：

-仅仅对于AUTOSAR域40，42，44

o诊断通信

CAN/FR：基于ISO-TP(国际标准组织-传输协议)的UDS(统一诊断服务)

ETH(以太网)：基于DoIP(互联网协议诊断)(UDP、TCP

(传输控制协议))的UDS

o诊断转发

CAN/FR：ISO-TP消息的消息路由

ETH：非诊断的TCP信道的DoIP路由

o非诊断的TCP信道

与CAN、FR、ETH相关：

o时间同步、网络管理、测量和校准(XCP)

-仅仅对于另外的域16，18，20

o具有PDU 72的帧70，其用于PDU和容器路由或/和由应用程序接收

-对于AUTOSAR域40，42，44以及对于另外的域16，18，20相关o仅仅对于ETH相关：

地址解析协议(ARP)

SOME/IP服务发现(SD)

用于所接收的PDU 72的转发决策92

从通信驱动器24向上转发到软件栈26中的帧70被进一步处理，以便提取通用的PDU 72和/或包含原子的、被包含的PDU 72的容器PDU 72。

根据在PDU网关28内部可配置的PDU转发决策92，将通用的PDU 72或者被包含(在容器74中)的PDU 72转发给以下目的地之一：

-仅仅AUTOSAR域40，42，44：仅仅与应用46，48(所述应用被托管在AUTOSAR域40，42，44中)的接收相关的PDU 72仅仅通过PDU适配器60转发给AUTOSAR PDU路由器54。

-仅仅与另外的域16，18，20相关：仅仅与PDU和容器路由相关的PDU 72被转发：

-当目标接口13位于相同的另外的域16，18，20中时，则往回向下转发到路由装置22的通信协议栈26和通信驱动器24中，以便进行传输。

-当目标接口13位于不同的另外的域16，18，20中时，转发给相应的另外的域16，18，20的PDU网关28，以便进行传输。

-不但对于AUTOSAR域40，42，44而且对于另外的域16，18，20：

-不但与由应用46，48进行的接收而且与PDU和容器路由相关的PDU 72不但被转发给AUTOSAR域40，42，44而且被转发给另外的域16，18，20的目标域。

来自AUTOSAR域40，42，44和另外的域16，18，20的PDU 72和帧70的传输的组合：

因为只有另外的域16，18，20具有对物理的接口13的直接的访问，因此来自AUTOSAR域40，42，44和另外的域16，18，20的传输数据必须被组合并且被传输到相关联的目标接口13(CAN/Flexray/以太网)的另外的域16，18，20上。

在AUTOSAR中的应用程序46，48的PDU 72

-来自不同的另外的域16，18，20和/或来自本地的另外的域16，18，20的域40，42，44在本地的另外的域16，18，20的PDU网关中组合，以便构建目标帧70的用户数据82。

来自AUTOSAR域40，42，44和本地的另外的域16，18，20中的基本软件52的帧70被在本地的另外的域16，18，20上的通信驱动器24传输给目标接口13。

用于不同的应用情形的数据路径

基于相应的应用情形，一定的部分量的处理、转发决策和数据路径在混合的软件架构中是相关的。在以下的段落中与图6-12相结合地解释用于不同的应用情形的数据路径。

在另外的域16，18，20中的一个以内的PDU和容器路由在图7中示出。对于这种应用情形，在另外的域16，18，20中的一个上所接收到的PDU 72和/或容器74(被包含在步骤88中所接收到的帧70中)被传输给相同的另外的域16，18，20的目标接口13(根据步骤106的相应的帧70的传输)(例如CAN到CAN路由)。因此，在软件栈26中的数据路径(步骤91，92，93，110，120)在另外的域16，18，20中的唯一的域以内上下来回，而不与AUTOSAR域40，42，44和不同的另外的域16，18，20发生数据交换。

在另外的域40，42，44之间的PDU和容器路由在图8(接收部分)或者图9(传输部分)中示出。对于这种应用情形(步骤88，90，91，92，94(图8)；步骤108，110，120，104，106(图9))，在源域16，18，20上所接收到的PDU 72和/或容器74首先被传输到目标域16，18，20上(在步骤88中接收相应的帧70，用于转发给PDU网关28的转发决策或者在接收PDU 72时在那里的转发决策，在步骤94中转发给相应的另外的目标域16，18，20)，在另外的目标域16，18，20中，在步骤108中从不同的另外的域16，18，20接收PDU 72，在步骤110中，进行将PDU 72组合传输给目标域16，18，20的通信驱动器24(步骤120)，其中，通信驱动器24在相关联的帧70中进行PDU 72的传输(步骤104)并且紧接着将其传输给相关联的接口13到目标域16，18，20的目标接口13上。

由AUTOSAR域40，42，44对帧70和PDU 72的接收和传输在图10中示出。对于这种应用情形，在另外的域16，18，20中的一个上所接收到的(步骤88)、与AUTOSAR域40，42，44相关的帧70(对此在转发决策90中例如数据头80和路由表求取)从另外的域16，18和20的通信驱动器24传输给AUTOSAR域40，42，44的虚拟的驱动器64(在步骤96中)。同样地，待从AUTOSAR域40，42，44传输的帧70首先被传输到另外的域16，18，20中的目标域中并且然后被传输给目标接口13。为此，在步骤100中，相应的虚拟的接口56将相应的帧70传输给虚拟的驱动器64。还位于AUTOSAR域40，42，44中的虚拟的驱动器64在步骤102中将相应的帧70传输给相关联的目标域16，18，20的通信驱动器24，并且然后通过步骤104到达相关联的接口13(参见步骤106)。

对于通过AUTOSAR域40，42，44接收和传输PDU 72的应用情形(图11)，从帧70中提取的通用的PDU 72或者所包含的PDU 72和在与AUTOSAR域40，42，44相关的另外的域16，18，20中的一个上所接收到的相应的容器74被传输到AUTOSAR域40，42，44中。在步骤88中所接收到的帧70在转发决策90中在相关性或者路由方面被检验，并且在步骤91中被传送给用于AUTOSAR域40，42，44的PDU 72的转发决策92。在步骤112中，通过PDU适配器60(通过步骤112)和PDU路由器54(步骤114)进行向AUTOSAR域40，42，44的传输。在从AUTOSAR域40，42，44传输PDU时，这在步骤116中从PDU路由器54向PDU适配器60地进行和在步骤118向PDU网关28地进行。在步骤110中，进行传输并且因此待传输的PDU 72在步骤120中到达通信驱动器24，其中，在步骤104中，进行到相应的另外的域16，18，20的相关联的帧70中的转换和接着向相应的接口13的传输(步骤106)。

应用情形的组合在图12中示出。除了以上提到的三个应用情形(用于帧70的转发决策、用于PDU 72的转发决策，来自AUTOSAR域40，42，44和另外的域16，18，20的PDU 72和帧70的组合地传输)之外，这些应用情形的组合是可能的。用于这样的应用情形的一个示例是由应用46，48接收PDU 72和在本地的另外的域16，18，20以内的PDU路由的组合。在这种情况下，所接收到的PDU 72通过到AUTOSAR域40，42，44上的PDU转发决策92(通过利用PDU适配器60的传输路径112，140)和通过在相同的另外的域16，18，20的软件栈26中的传输路径93，110，120，104划分。混合的软件架构支持应用情形的另外的这样的组合。

用于数据路由的另外的域16，18，20的集成的外接工具链(Offboard-Toolchain)在图13中示出。混合的软件架构在嵌入式软件中的实现必须通过调整所谓的外接工具链或者开发环境和用于生成控制设备配置和相应地生成ECU闪存容器146的工作流程来补充。混合的软件架构将控制设备功能的完整的范围基本上划分为AUTOSAR域部分和另外的域部分。因此，调整工具链(见图13)，以便从完整的控制设备配置中得出AUTOSAR域和另外的域专用的配置。

通过被包含在用于产生用于另外的域16，18，20的配置数据140，142的工具132中的配置划分134将在系统说明(*.arxml)的所谓的完整的AUTOSAR控制设备提取130中所定义的AUTOSAR控制设备配置划分为数据路由专用的配置(如其对于另外的域16，18，20是需要的)，所述数据路由专用的配置存储在(另外的域16，18，20的)连接在中间的数据模型136和AUTOSAR专用的配置中，所述AUTOSAR专用的配置是缩减的AUTOSAR控制设备提取150。即，缩减的AUTOSAR控制设备提取150的内容是完整的AUTOSAR控制设备提取130的内容减去被分派给用于数据路由的另外的域16，18，20的数据模型136的部分。数据路由配置代码(*.c，*.h)由数据路由数据模型136生成。

用于产生用于另外的域16，18，20的配置数据的工具132集成在软件开发工具链和工作流程的切入点上。例如车辆制造商的完整的AUTOSAR控制设备提取130被输入到工具132中，以便得出配置代码140和缩减的AUTOSAR控制设备提取150。该缩减的AUTOSAR控制设备提取150尽管在范围上缩减，但是是一致的并且因此可以被输入到各个AUTOSAR配置工具和代码生成器152中，以便生成AUTOSAR配置代码154。不但(另外的域16，18，20的)路由单元22的静态的代码142(*.c，*.h)而且静态的AUTOSAR代码156(*.c，*.h)而且路由单元22的配置代码140以及AUTOSAR配置代码154被提供给编译器或者链接器(Linker)，所述编译器或者链接器对它们进行编译并且使它们联系起来，以便生成完整的控制设备SW闪存容器146，通过所述完整的控制设备SW闪存容器可以将软件更新闪存到控制设备5中。

另外的域16，18，20的路由单元的数据模型136是一种紧凑的以控制设备为中心的对象模型，从复杂的和冗余的以车辆为中心的AUTOSAR数据模型得出所述对象模型的内容。在生成配置代码140之前，路由单元专用的配置以另外的域16，18，20的路由单元的数据模型136的格式缓存在工具132中。这种格式实现对数据流和网关3的通信关系的更简单地可视化和分析。

数据模型136(见图14)以定向的非循环的图(DAG)的形式描绘在网关3中的数据流，所述定向的非循环的图由角点(节点)组成，所述角点(节点)与单向的边(箭头)连接。端点-角点表示数据的源200和沉240(通信控制器202(接收例如CAN)，242(传输例如CAN)；214(接收例如FR(Flexray)，258(传输例如FR)，210(接收例如ETH套接字)，246(传输例如ETH套接字，AUTOSAR基本软件220，AUTOSAR软件部件230)。中间角点表示在网关中的处理步骤(接收(204(接收CAN帧)，207(接收CAN容器PDU)，209(接收CAN通用PDU)，212(接收ETH通用的/所包含的PDU)，216(接收FR帧)，223(接收FR容器，PDU)，226(接收通用的PDU))解包(208(CAN解包PDU)，224(FR解包PDU))尤其是在CAN、FR中的PDU，转发，打包(233(CAN打包PDU)，250(FR打包PDU))，发送(223(CAN发送所包含的PDU，248(FR发送所包含的PDU)，235(CAN发送容器PDU)，252(FR发送容器PDU)，253(FR发送通用的PDU)，256(FR发送帧)，260(AUTOSARCAN发送帧)，262(AUTOSAR FR发送帧)，270(CAN发送帧)，相互连接的边表示通信数据单元(帧70，PDU 72，通用PDU 72)包括它们的相互关系(帧70的PDU 72)和它们的处理在时间上的顺序在内。这些角点和边附加地具有更精确地描述它们的特性。

所提出的用于具有集成的网关功能的汽车控制装置的混合多核软件架构为所讨论的问题情况提供最佳的解决方案。它将AUTOSAR标准软件架构的优点与专有的路由单元软件架构相组合，以便解决车辆功能或者网关功能(高性能的数据转发)的托管的应用情形。除了对嵌入式的软件的必需的调整的说明之外，也说明了工具132的必需的扩展和集成。

Claims (14)

1.用于在车辆的通信系统(11)中转发数据的方法，其中，所述通信系统(11)包括至少一个第一总线系统(10，12，14)和至少一个另外的总线系统(10，12，14)，其中，数据能够在所述总线系统(10，12，14)之间被交换，与作为独立的实施实例的至少一个第一域(40，42，44)、尤其是AUTOSAR域(40，42，44)进行交换，其中，在所述第一域(40，42，44)中能够实施应用程序(46，48)、尤其是车辆功能，其中，所述第一域(40，42，44)包括到所述应用程序(46，48)的、至少标准化的接口，尤其是AUTOSAR实时环境，其中，通过作为与所述第一域(40，42，44)独立的另外的实施实例的另外的域(16，18，20)进行在所述通信系统(11)和所述第一域(40)之间的数据的交换，其方式是，仅仅通过所述另外的域(16，18，20)访问所述通信系统(11)的物理的接口(13)，其中，至少在转发方面处理通过所述通信系统(11)的物理的接口(13)在所述另外的域(16，18，20)中所接收到的数据(70，72，74)。

2.根据权利要求1所述的方法，其特征在于，所述数据包括至少一个数据单元(72)、尤其是AUTOSARI-PDU或者随后的协议数据单元(PDU)，其中，所述数据单元(72)能够被包含在通过所述物理的接口(13)传送的帧(70)中和/或被包含在所述帧(70)中的容器(74)中，其中，所述数据单元(72)和/或所述容器(74)包括至少一个数据头(80)和用户数据(82)、尤其是如具有物理的或者功能上的相关性的信号这样的应用数据。

3.根据以上权利要求中任一项所述的方法，其特征在于，对于第一总线系统(10，12，14)，使用自身的另外的域(16，18，20)，并且对于另外的总线系统(10，12，14)，使用另外的自身的另外的域(16，18，20)，其中，在两个另外的域(16，18，20)之间的数据交换仅仅在数据单元(72)的层级上进行，尤其是在通用的数据单元(72)和/或被包含在容器(74)中的数据单元(72)的层级上进行。

4.根据以上权利要求中任一项所述的方法，其特征在于，在所述另外的域(16，18，20)中转发这样的数据：所述数据尤其涉及与高性能相关的应用数据，所述应用数据在尤其是在控制设备(5)上的车辆功能之间交换，尤其是在行驶的车辆中。

5.根据以上权利要求中任一项所述的方法，其特征在于，在所述第一域和所述另外的域(16，18，20；40，42，44)之间，数据可以在帧(70)的层级上和/或在数据单元(72)的层级上尤其是通过使用被两个域(16，18，20；40，42，44)共有的存储器交换，而在所述另外的域(16，18，20)中的一个另外的域与所述另外的域(16，18，20)中的一个不同的另外的域之间，数据仅仅在所述数据单元(72)的层级上交换、然而不在所述帧(70)的层级上交换。

6.根据以上权利要求中任一项所述的方法，其特征在于，所述与高性能相关的数据保留在所述另外的域(16，18，20)中用于进一步处理，而另外的数据被转发给所述第一域(40)。

7.根据以上权利要求中任一项所述的方法，其特征在于，从所述通信驱动器(24)向协议存储器或者协议栈(26)所转发的帧(70)通过所述另外的域(16，18，20)进一步处理，其方式是，从所述帧(70)和/或容器(74)中提取尤其通用的数据单元(72)和/或被包含在容器(74)中的数据单元(72)。

8.根据以上权利要求中任一项所述的方法，其特征在于，在所述第一域(40)中，执行如本地终端(由被托管的车辆功能进行的接收和传输)、传输协议、诊断通信、诊断路由、网络管理这样的应用情形。

9.根据以上权利要求中任一项所述的方法，其特征在于，用于所接收的帧(70)的转发决策(90)区分，是否存在着具有数据单元(72)和/或容器(74)的帧(70)用于转发和/或是否设置由应用进行接收。

10.根据以上权利要求中任一项所述的方法，其特征在于，所述另外的域(16，18，20)包括至少一个驱动器(24)，其用于连接在所述通信系统(11)、尤其是总线系统(10，12，14)的物理的接口(13)上，尤其是以便进行数据访问或者用于ISO/OSI第2层的控制机制，和/或所述另外的域(16，18，20)包括至少一个协议存储器或者协议栈(26)，尤其是用于数据访问或者用于ISO/OSI第3-5层的控制机制，所述控制机制对于处理在所述另外的域(14，16，18)上的高性能相关的数据是必需的，和/或所述另外的域(16，18，20)包括至少一个网关(28)，其用于转发至少一个数据单元(72)，尤其是在不同的另外的域(16，18，20)的协议栈(26)之间。

11.根据以上权利要求中任一项所述的方法，其特征在于，在所述第一域(40，42，44)中，为帧(74)设置至少一个虚拟的驱动器(58，60，62，64)，尤其是作为真实的驱动器的代理，特别优选AUTOSAR复杂设备驱动器(CDD)，以便在所述第一域和所述另外的域(16，18，20；40，42，44)之间与所述另外的域(40，42，44)的相应的驱动器(24)交换帧(74)，和/或以便与设置在所述第一域(40，42，44)中的接口(56)、尤其是AUTOSAR协议接口交换，和/或在所述第一域(40，42，44)中，为所述数据单元(72)设置至少一个适配器(60)，其用于与所述另外的域(16，18，20)的网关(28)交换数据或者数据单元(72)和/或用于与设置在所述第一域(40，42，44)中的路由器(54)、尤其是AUTOSAR PUD路由器、特别优选AUTOSAR复杂设备驱动器(CDD)交换。

12.根据以上权利要求中任一项所述的方法，其特征在于，从所述第一域(40，42，44)的系统说明(130)、尤其是完整的AUTOSAR控制设备提取中生成与所述数据在所述另外的域(16，18，20)中的转发相关的配置代码(140，142)和/或所述第一域(150)的缩减的系统说明、尤其是缩减的AUTOSAR控制设备提取。

13.根据以上权利要求中任一项所述的方法，其特征在于，至少所述另外的域(16，18，20)的配置代码(140)和所述第一域(40，42，44)的配置代码(154)被提供给编译器或者链接器(144)，以便创建控制设备(5)的闪存容器(146)。

14.根据以上权利要求中任一项所述的方法，其特征在于，通过使用说明所述数据(136)的转发的数据模型(136)产生所述配置代码(140，142)。