AUTOSAR中的虚拟电子控制单元的制作方法

本发明涉及包含多个核的电子控制单元(ecu)。

背景技术：

汽车开放系统架构或autosar标准化了现代汽车中使用的电子和软件架构，目的是简化与车辆相关的软件功能的开发和集成。

现代汽车现在能够支持许多复杂功能，包括自导航和操纵、先进的发动机排放控制、基于图像检测的服务以及用于改进汽车动力学的复杂控制算法。

因此，嵌入在车辆中的电子控制单元(ecu)的数量正在稳步增加，并且现今对于单个汽车可以达到多于100个ecu。

鉴于这种发展，现代电子控制单元(ecu)配备有多个核，以增强计算能力并提供软件功能能力。

然而，原始的autosar标准定义了通常被分配给具有单核特征的软件架构的系统服务。

于是，autosar标准通常无法利用在多个电子控制单元(ecu)核上并行执行应用的益处。

autosar4.0标准通过规定所有核应当在相同(共享)的代码库上运行以减少操作系统(os)在内存中的占用来指定多核支持。因此，所有核使用相同的代码库，这意味着一次仅一个核可以执行autosar软件架构的基础软件(bsw)，其中，由所有核执行的唯一部分是操作系统(os)，各个核具有分离的数据结构。

autosar标准还提出了应将os间应用通信器(ioc)与软件架构的运行时环境(rte)结合使用，以映射跨核和内存分区边界的通信。然而，由于os间应用通信器(ioc)使用发送方-接收方协议进行操作(例如，通过实现数据内存缓冲器)，所以对时间关键型数据传输进行适当地调度(scheduling)和对应地执行是一项具有挑战性的任务，尤其是当试图实现高度并行运行多个核时。

虚拟化技术已经用于整合多个autosarecu配置，例如，通过隔离各个常规的单(或较少数量的)核ecu配置的操作，将多个单核autosarecu集成在单个平台中。

以此方式，系统可以托管(host)多个分区，其中，各个分区充当一个独立的虚拟机(vm)，并且各个虚拟机(vm)可以运行一个单独的操作系统(os)，例如用于运行单个核。

因此，例如，可以在单个电子控制单元(ecu)中实现多个常规的单核电子控制单元(ecu)配置。以此方式，在合并基于单核的软件结构时，可以采用多个核而无需进行大量的重新验证和测试工作。

然而，虚拟并行化的这种概念要求用于虚拟化过程的管理程序必须抽象化硬件平台，并且必须并行运行多个操作系统(os)，以允许从所有核访问所有硬件服务。

此外，在单独的并行autosar栈的上下文中运行并行操作系统(os)导致rom和ram消耗大量开销，使并行运行的驱动和应用(例如以太网驱动)的时间处理、握手处理和内存处理变得复杂。

因此，在不同分区上并行运行的软件之间的通信处理变得困难，并且可能需要复杂的共享资源和服务处理，以确保整个系统的运行安全可靠。

技术实现要素：

鉴于以上所述，本发明的目的是当使用包含多个核的电子控制单元(ecu)时，改进与autosar相关的服务的实现，并且尤其是减少针对实现新功能的测试工作。

更具体地，根据本发明的一方面，电子控制单元(ecu)优选包含多个核，其中：

·电子控制单元(ecu)优选通过虚拟化来托管包括第一分区和第二分区的多个分区，

·优选将分区中的每一个分配给所述核中的至少一个，

·第一分区被实现成在其至少一个核上运行提供autosar基础软件(bsw)服务的autosar架构平台实例(即autosar架构平台实例)，并且

·第二分区被实现成在其至少一个核上运行autosar软件部件(swc)，其中，分区接口耦合第一分区和第二分区，使得autosar软件部件(swc)作为在第一分区中实现的所述autosar架构平台实例的一部分运行。

因此，应用虚拟化技术以使电子控制单元(ecu)托管用于运行多个核的多个分区。因此，ecu可以包含cpu(中央处理单元)，该cpu包含几个单独的处理器，即核。

第一分区和第二分区中的每一个被分配给至少一个核。因此，为各个分区提供单核或多核的计算资源。然而，优选的是，核不被多个分区共享，即，每个核被分配给所述分区中的仅一个，因为不同的布置可能导致不期望的运行时依赖性，从而恶化分区中的每一个的独立性。

要注意的是，可以并行地使用运行autosar软件部件(swc)的多于一个的分区(例如，本文提到的第二分区和第三分区)。当使用运行autosar软件部件(swc)的更多分区时，本发明提供更多优点，其中，同时仅需要一个提供autosar基础软件(bsw)服务的第一分区。换句话说，仅包含bsw服务的一个分区可以与运行swc的n个分区组合，总共产生n+1个分区。因此，本文所公开的ecu可以充当多域控制器，并且因此可以组合不同常规控制单元(例如，在单个壳体(housing)中和/或在单个ecu中)的功能。例如，可以将提供autosar基础软件(bsw)服务的一个分区与几个(尤其是与2、3、4、6、8、10或12个)运行autosar软件部件(swc)的分区进行组合。如本文所述的分区也可以被称为“智能-vip”(“虚拟分区”)。

第一分区被实现成运行autosar架构平台实例。更具体地，应用虚拟化技术以将充当第一分区的虚拟机部署成提供autosar基础软件(bsw)服务的autosar软件实例。

根据autosar标准，各基础软件(bsw)服务可以包括多于40个的定义的模块，并且因此可以构成autosar系统的最大部分。基础软件(bsw)提供(其它)软件部件(swc)所需的服务，以便实现其功能，例如，软件部件(swc)被实现成提供车辆自导航和操纵、先进的发动机排放控制、基于图像检测的服务或复杂的控制算法，以改进汽车动力学。

根据autosar标准，基础软件(bsw)是分层构建的，例如：服务层向软件部件(swc)和其它基础软件(bsw)模块提供包括操作系统(os)的基本服务；电子控制单元(ecu)抽象层对由电子控制单元(ecu)硬件提供的更容易访问的服务进行抽象化；微控制器抽象层对具体的微控制器架构进行抽象化以改进透明度；并且复杂驱动层提供附加的可能与autosar不兼容的功能和驱动，包括例如启用硬件连接的旧版驱动。

换句话说，除其它以外，autosar软件部件(swc)是正式定义的软件部件，具有到基础软件(bsw)的指定分区接口。该基础软件进而可以提供基本的标准服务，例如总线通信(例如can、以太网或flexray)、内存管理、io(输入/输出)-访问、系统和诊断服务。

按照惯例，虚拟化技术被用于在单个平台上整合多个autosarecu配置，其中，几个托管分区中的每一个充当独立的虚拟机(vm)，运行不同的autosar基础软件(bsw)模块实例。尤其是，按照惯例，autosar基础软件(bsw)模块的各个实例都配置有由单独的管理程序管理的其自己的资源(核、内存、i/o等)。

如上所述，独立的autosar分区栈的这种布置会导致rom和ram消耗大量开销，使并行运行的驱动和应用的时间处理、握手处理和内存处理变得复杂，并且使在不同分区中并行运行的软件之间的通信的操作和诊断变得复杂。

鉴于此，根据本发明，第一分区被实现成运行autosar架构平台实例，而第二分区的软件被实现成作为第一分区提供的autosar架构平台实例的一部分运行。优选地，第一分区被实现成仅运行autosar架构平台实例，而第二分区(或第三分区)的软件被实现成仅作为第一分区提供的autosar架构平台实例的一部分运行。因此，不是复制用于第二分区的autosar架构平台实例，而是将第二分区定义成包括autosar软件部件(swc)，其中，分区接口耦合第一分区和第二分区。

以此方式，在第二分区的至少一个核上运行的autosar软件部件(swc)可以适于使用由在第一分区中实现的所述autosar架构平台实例提供的autosar基础软件(bsw)服务。

于是，根据本发明，仅在一个分区中实现了autosar栈，但是由仅运行autosar软件部件(swc)的分区的autosar软件使用或例如由第一分区和第二分区使用。于是，规避了并行运行在不同分区中实现的常规多个autosar架构平台实例的需求，降低了对应内存管理、握手算法和分区间通信技术的复杂性和要求。

在示例中，由电子控制单元(ecu)托管的多个分区包括第三分区，该第三分区被实现成在其至少一个核上运行其它autosar软件部件(swc)。此外，提供了分区接口以耦合第一分区和第三分区，使得第三分区的autosar软件部件(swc)作为在第一分区中实现的所述autosar架构平台实例的一部分运行。

换句话说，autosar栈在第一分区中实现，但由第一分区、第二分区和第三分区的autosar软件使用。因此，在该情况下，也规避了并行运行在不同分区中实现的常规多个autosar架构平台实例的需求，降低了对应内存管理、握手算法和分区间通信技术的复杂性和要求。

优选地，第一分区仅包含autosar基础软件(bsw)服务而没有(其它)autosar软件部件(swc)。对应地，第二分区和/或第三分区和/或任何其它分区可以仅包含autosar软件部件(swc)，而没有autosar基础软件(bsw)服务。然后，第二分区和/或第三分区(以及任何其它分区)的autosar软件可以使用在第一分区中实现的autosar栈。

第一分区可以适于充当第二分区和/或第三分区(以及任何其它分区)的数据接口。例如，只有第一分区可以使用或提供can-总线栈或can-总线通道。这意味着从第二分区和/或第三分区传送或传送到第二分区和/或第三分区的数据通过第一分区进行路由。第二分区与第三分区之间不允许直接通信。

要注意，在第二分区和第三分区中实现分离的autosar软件部件(swc)允许清晰可靠地分离已实现的软件功能，改进了软件架构的透明度，并简化了整个软件开发过程。尤其是，可以通过精益的管理程序来保证可靠的安全防护以防止分区之间的干扰，其中，精益的管理程序执行不同分区的安全启动。精益的管理程序可以包含监视数据访问的内存保护单元(mpu)。

此外，第二分区的autosar软件部件(swc)和第三分区的autosar软件部件(swc)可以通过分别刷新各分区的内存(memoryflashing)来实现。

优选地，为此目的，第一分区、第二分区和第三分区的刷新内存地址和地址范围在刷新之前是固定的，并且还优选地在刷新操作之间保持固定。以此方式，可以分别对分区进行刷新，使得能够针对分区中的每一个进行单独的软件开发，简化基于分区的内存比较，并使得能够更容易地调试/更新各个单独的分区提供的软件应用。

优选地，耦合第一分区和第二分区的分区接口被实现为autosar架构平台实例的代理软件部件(swc)(即，在第一分区中)。以此方式，通信通道被限于在autosar环境内提供增强的运行时性能和可测试性的autosar固有代理软件部件(swc)。

按照惯例，autosar提出了应将os间应用通信器(ioc)用于在链接到不同操作系统(os)或链接到相同或不同核的软件部件(swc)之间进行通信。在该方面，os间应用通信器(ioc)使用经由数据内存缓冲器执行的发送方-接收方协议来进行操作。

在一个实施方式中，ioc可以用于促进第一分区与第二分区之间以及第一分区与第三分区之间的通信。与常规ioc相比，该ioc可以用于传送包含多个信号的数据包，例如，测量信号(而不是传送信号本身)。取决于时间限制，这些数据包可以包含预定义的持续时间(例如，5ms、10ms或20ms)的信号。

此外，可以在任务级别而不是在中断级别执行不同分区之间的数据通信。这意味着可以通过任务(例如第二分区或第三分区的任务)来发起数据传送。

另外，可以提供用于在引导加载程序(bootloader)与分区之间交换数据的数据区域。

此外，耦合第一分区和第三分区的分区接口可以被实现为autosar架构平台实例的代理软件部件(swc)。

优选地，第二分区的autosar软件部件(swc)适于通过使用分别耦合第一分区和第二分区以及第一分区和第三分区的分区接口与第三分区的autosar软件部件(swc)通信。

以此方式，不同分区的autosar软件部件(swc)之间的通信经由托管操作系统(os)的第一分区进行传递，使得能够以集中的方法来改进多核系统内数据传输的同步、时间调度和整体监测。

这对于第一分区的操作系统(os)以协调方式收集和分发信号尤其有用，其中，信号由属于电子控制单元(ecu)其它且不同分区的autosar软件部件(swc)生成和接收。

还优选的是，第一分区适于在属于电子控制单元(ecu)的不同分区的autosar软件部件(swc)之间传递所有通信。这进一步增强了使第一分区在多核系统内以集中的方式执行分区间数据传输的相应同步、时间调度和/或监测的益处。

在示例中，在第一分区中实现的操作系统(os)被配置成调度和/或定时(time)监测在第二分区和/或第三分区的核上运行的autosar软件部件(swc)。

以此方式，可以通过第一分区的操作系统(os)，例如通过在第一分区中实现的任务管理器，以高效且集中的方式来处理分布式软件应用的执行以及处理数据和数据共享的对应协调。当在系统中实现高度并行化时，例如其中，第一分区、第二分区和/或第三分区各自被分配给至少两个核时，这尤其有用。

为此目的，优选的是，在第一分区中实现的操作系统(os)设置有在第二分区或第三分区的核上运行的autosar软件部件(swc)的固定起始地址，以使得操作系统(os)能够调度和发起各autosar软件部件(swc)的执行。在执行更新时，固定的起始地址需要具有二进制兼容的分区，例如如果分区的功能未改变。固定的起始地址可以是先前定义的地址，和/或可以经由跳转表或类似的措施来提供。

还优选的是，第一分区充当用于电子控制单元中运行的所有分区到外部装置的外部接口。因此，例如从第二分区和/或第三分区到外部装置的所有数据通信通过第一分区进行路由和/或由第一分区的bsw促成。

另选地，可以直接在各分区之间执行属于电子控制单元(ecu)的不同分区的autosar软件部件(swc)之间的至少一些通信。然后，各个分区可以包含分布式通信栈(com-栈)。

本发明还涉及车辆，例如自主驾驶汽车，该车辆包含如本文所公开的电子控制单元。

另外，本发明涉及执行autosar软件部件的方法，其中

·通过虚拟化托管包括第一分区和第二分区的多个分区，

·分区中的每一个被分配给ecu的核中的至少一个，

·第一分区被实现成优选在其至少一个核上运行提供autosar基础软件(bsw)服务的autosar架构平台实例(即autosar架构平台实例)，以及

·第二分区被实现成优选在其至少一个核上运行autosar软件部件(swc)，其中，第一分区和第二分区被耦合，使得autosar软件部件(swc)作为在第一分区中实现的所述autosar架构平台实例的一部分运行。

另一优点是，有助于对改变/修改的(尤其是第二分区和第三分区的)软件部分的测试。

例如，第一分区可以提供bsw服务，而第二分区可以提供用于标准汽车功能(如abs(防抱死制动系统)或照明功能控制)的swc。第二分区中的软件可能已经被良好的测试，并且不要求进一步开发。相反，第三分区可以提供允许车辆的自主驾驶的swc/软件。因此，第三分区的软件可以相当频繁地被更新、改变或修改。

例如，在当仅第三分区的软件已经被改变的情况下，优选地在外部接口或分区接口中没有改变的情况下，可能仅需要完全测试第三分区的新软件。然后可能不需要测试第一分区和第二分区。在该情况下，可以对第一分区和/或第二分区的软件执行二进制比较。然后，该二进制比较可以指示第一分区和/或第二分区的软件是未改变的，并且因此可以预期其照常运行。

通常，该方法因此可以包含

·改变第二分区和/或第三分区的仅一个软件，其中，所有外部接口或分区接口保持不变，

·优选地，仅对未改变的分区的软件执行二进制比较，以便验证未改变的分区实际上是未改变的。

除了二进制比较(与该分区在改变另一分区前的版本进行二进制比较)外，可以仅测试改变的分区(即，可以执行第一分区的接口时序测试或者第二分区或第三分区的测试)。

另选地，可以改变外部接口和/或分区接口。可选地，改变第二分区或第三分区中的一个(或仅一个)，在这种情况下，可以对改变的接口的时序进行测试，并可以对未改变的分区执行二进制比较。时序测试可以包含接口的静态和/或动态测试，以便确保各个分区将提供所需的功能。优选地，不进行其它测试以减少测试工作。

在执行接口时序测试时，尤其是在最坏的情况下，可以执行延时测量。通常，接口和/或分区的测试可以在软件在环(software-in-the-loop)(sil)或甚至在硬件在环(hardware-in-the-loop)(hil)的环境中进行和/或可以自动地进行。

在一个实施方式中，可以确定的是，第二分区或第三分区中的一个与第一分区不兼容。在该情况下，不兼容的分区然后可以被停用，例如，借助于对控制单元的参数进行编码。另选地，可以执行功能降级，以使得不兼容的分区能够在功能减少的基础上进行协作。

本文关于发明控制单元公开的其它优点和实施方式也适用于发明车辆和发明方法(反之亦然)。

附图说明

在以下附图描述中描述了本发明的进一步的实施方式。下面借助于实施方式并参照附图对本发明进行说明，其中：

图1示出了用于多核系统的现有虚拟化概念；

图2示出了根据本发明的虚拟化概念；

图3示出了通过虚拟化概念部署的三个分区；以及

图4示出了多分区系统中的集中通信。

在下文中，关于部件的方向做出的任何陈述是相对于附图中所示的位置做出的，并且自然可以在实际应用位置中变化。

参考数字列表

100电子控制单元(ecu)

110-130分区

210-250核

310-320autosar基础软件(bsw)

410-450autosar软件部件(swc)

510-520分区接口耦合

610-640代理软件部件模块

710操作系统(os)

具体实施方式

图1示出了应用于电子控制单元100的现有技术虚拟化概念，其中，电子控制单元100包括多个核210至250。

在该示例中，虚拟化概念已经用于在单个平台中整合两个单独的autosarecu配置。

更具体地，系统托管两个不同的分区110、120，其中，各个分区110、120充当独立的虚拟机(vm)。第一分区110被分配给两个核210、220，并且第二分区120被分配给底层电子控制单元100的剩余三个核230、240、250。

各个虚拟机(vm)运行分层构建的基础软件310、320。在该示例中，各个基础软件310、320分别向各个autosarecu配置的软件部件410至450和其它基础软件320、320提供包括单独的操作系统(os)的服务的基本服务。

于是，可以在单个电子控制单元(ecu)中实现多个常规的autosarecu配置，以便利用多个核210至250。

然而，如上所述，虚拟并行化的这种概念要求用于虚拟化过程的管理程序必须抽象化硬件平台并且并行运行多个操作系统(os)，以允许从所有核210至250访问所有硬件服务。

此外，在单独的并行autosar栈的上下文中运行并行操作系统(os)导致rom和ram消耗大量开销，使并行运行的驱动和应用(例如以太网驱动)的时间处理、握手处理和内存处理变得复杂。

因此，在不同分区110、120上并行运行的软件之间的通信处理变得非常困难，并且可能需要复杂的诊断任务以确保整个系统的运行安全可靠。

因此，图1示出了以常规方式实现的os间应用通信器(ioc)模块510、520，以映射分区110、120之间的通信。为此目的，os间应用通信器(ioc)模块510、520被配置并耦合成例如通过实现的数据内存缓冲器来运行发送方-接收方协议。然而，如上所述，应用这种布置可能是困难和复杂的，尤其是在试图实现高度并行运行大量核时。

鉴于此，图2示出了根据本发明的不同的虚拟化概念。

在该布置中，也应用虚拟化技术以使电子控制单元100托管用于运行多个核210至250的多个分区110、120。此外，第一分区110被分配给两个核210、220，并且第二分区被分配给剩余三个核230至250。

然而，与图1所示的常规方法相比，仅第一分区110被实现成运行提供autosar基础软件310服务的autosar架构平台实例。

如上所述，基础软件310将第一分区的其它软件部件410、420所需的服务提供给例如被分配给在第一分区中的第二核220上运行的软件部件420。

尤其是，基础软件310包括操作系统(os)和抽象层，以使得能够更容易地访问与电子控制单元(ecu)的硬件相关的服务和驱动。

不是复制图1所示的用于第二分区120的autosar架构平台实例，图2提出了不同的布置。这里，第二分区120包括被分配给第二分区120的不同核230至250的autosar软件部件430至450，但是第二分区120不包括任何基础软件模块，例如，包括单独的操作系统(os)的基础软件模块。

此外，通过实现分区接口以耦合第一分区110和第二分区120，第二分区的软件部件(swc)作为在第一分区中实现的autosar架构平台实例的一部分运行。

更具体地，在第二分区120的三个核230至250上运行的autosar软件部件430至450适于使用在第一分区110中实现的autosar基础软件310。

于是根据本发明，包括基础软件310的autosar栈仅在分区中的一个110中实现，但是被第一分区110和第二分区120二者的autosar软件310、410至450使用。因此，规避了在不同分区中实现多个autosar实例所需的常规内存管理、握手算法和分区间通信技术。

在图2的示例中，耦合第一分区110和第二分区120的分区接口被实现为autosar架构平台实例的代理软件部件(swc)。以此方式，通信通道被限于在autosar环境内提供增强的运行时性能和可测试性的autosar固有代理软件部件(swc)。

图3示出了根据本发明的不同布置，其中，应用虚拟化技术以使电子控制单元100托管用于运行多个核210至250的三个分区110、120、130。

在该布置中，第一分区110仅被分配给一个核210，第二分区被分配给两个核220、230，并且新的第三分区130被分配给剩余两个核240、250。

除了耦合第一分区110和第二分区120的分区接口外，该布置还包括耦合第一分区和第三分区的另外的分区接口。在该示例中，耦合第一分区110和第二分区120的分区接口以及耦合第一分区110和第三分区130的分区接口二者都被实现为autosar架构平台实例的代理软件部件(swc)。这改进了autosar环境内的运行时性能和可测试性。

因此，被分配给第三分区130的核240、250的autosar软件部件440、450通过相应的分区接口耦合，以作为在第一分区110中实现的所述autosar架构平台实例的一部分运行。

换句话说，单个autosar栈在第一分区110中实现，并被第一分区110、第二分区120和第三分区130的autosar软件使用。因此，在该情况下，也规避了并行运行在不同分区中实现的常规多个autosar架构平台实例的需求，降低了对应内存管理、握手算法和分区间通信技术的复杂性和要求。

在第二分区120中实现autosar软件部件420、430以及在第三分区130中实现autosar软件部件440、450的另一优点是，可以通过分别刷新各分区120、130的内存来执行该实现。

在该示例中，第一分区110、第二分区120和第三分区130的刷新内存地址和地址范围在刷新之前是固定的，并且在刷新操作之间保持固定。因此，可以基于分区110、120、130各自的刷新内存地址和地址范围来分别对其进行刷新，以使得能够针对分区110、120、130中的每一个进行单独的软件开发，简化基于分区的内存比较，并使得能够更容易地调试/更新由各个单独的分区110、120、130提供的软件应用。

因此，相应的分区接口耦合第一分区110和第二分区120以及第一分区110和第三分区130。图4中示出了该布置，其中，分区接口510、520提供了在不同的分区110、120、130中实现的代理软件部件模块610至640之间的耦合。

于是，第二分区120的autosar软件部件420、430可以通过使用分别耦合第一分区110和第二分区120的分区接口510以及耦合第一分区110和第三分区130的分区接口520与第三分区130的autosar软件部件440、450进行通信。

图4示出了经由托管底层操作系统710的第一分区110传递的不同分区120、130的autosar软件部件420至450之间的对应通信。于是，为多分区系统提供了有效且透明的通信方案，使得能够以集中的方法来改进多核系统内数据传输的同步、时间调度和整体监测。

这对于由第一分区110的操作系统710以协调的方式收集和分发信号尤其有用，其中，图4中示出了要由属于电子控制单元(ecu)的不同分区120、130的autosar软件部件420至450生成和接收的信号。

另一优点是减少了测试工作。例如，如果第一分区110和第三分区130的软件被改变(即被进一步开发)，则所改变的软件被刷新到各自的内存地址范围中。之后，执行第二分区120的软件的二进制比较，以确保第二分区没有被改变。无需对第二分区120进行全面测试。而是，仅需要执行针对第二分区120的功能的接口(动态和静态)测试。另外，对所改变的第一分区110和第三分区130的功能进行测试。

从而，可以大大减少所需的测试工作。