用于执行机动车用户功能的计算机系统和方法

技术领域

本发明涉及用于执行用户功能特别是机动车用户功能(automotive customerfunction)的计算机系统，其中，用户功能生成用户功能输出数据，基于该用户功能输出数据对机器特别是机动车进行控制，其中，计算机系统包括一个或更多个处理核。

此外，本发明涉及用于在计算机系统中执行用户功能特别是机动车用户功能的方法，其中，用户功能生成用户功能输出数据，基于该用户功能输出数据对机器特别是机动车进行控制，其中，计算机系统包括一个或更多个处理核。

背景技术

现代实时系统特别是机动车实时系统包括许多复杂的软件部件以处理复杂性并简化开发。自动驾驶功能如高速公路领航系统(highway pilot)被分解为既依次参与又可能并行参与以实现车辆的相应功能的多个较小的部件。

对于这样的实时系统，能够确定并保证从观察到车辆的环境至车辆的物理反应的最坏情况的端到端计算延迟是至关重要的。例如，如果车辆的传感器子系统记录到车辆前方的障碍物，则必须在一定时间内启动车辆级反应(转向或制动)来避免碰撞以防止人身伤害。

这样的处理链(以下称为计算链)的范围从处理传感器输入到计算世界模型和生成致动器命令，并且通常包括大量单独的软件部件。可以存在许多同时执行的功能。因此，许多独立的计算链被同时执行。这些软件部件可以具有强烈变化的复杂性和运行时行为。

计算链可以分布在多个处理单元甚至ECU上，但是还可以在单个处理元件(例如，例如包括多个核以及可选的加速器的单个CPU)上执行。

这样的处理元件还包括许多并行和潜在多样化的处理单元(CPU核、GPU、用户设计的逻辑等)。通常，不可能同时满足所有软件部件的处理需求。需要仲裁机制以使最关键的任务能够被优先处理。此外，并行处理单元并非100％独立的，并且在一个部分上的软件执行可以对在另一部分上执行的软件产生负面影响。必须知道并控制该干扰。

另一重要特征是功能可以具有不同的危急程度，意指当功能未正确和及时地提供时对人类的风险有多严重。在此基础上提供不同水平的工程严谨性是最先进的。因此，不能保证低危急SWC(软件部件)的行为正确。需要保护关键SWC免受这样的潜在故障SWC的影响以防止安全关键故障，特别是包括导致影响关键SWC的时序的故障。

因此，计算链可以具有不同的优先级，并且甚至计算链内的不同部件也可以具有不同的重要性。存在必须要解决的在计算链之间以及计算链内部对共享资源的竞争。

典型的计算机系统还可以包括操作系统、中间件和大量的应用软件部件。

操作系统有责任确定在给定时间允许哪些任务使用哪些处理单元。然而，操作系统对任务的顺序或连通性一无所知。因此，操作系统自身无法直接保证任何端到端延迟。

为了增强操作系统，可以使用中间件和平台(计算机系统)调度器。

确定作为整体的多个协作的或独立的应用的所有同时执行的软件部件的实时需求是主要的开发活动，该开发活动需要应用开发人员侧和系统集成人员侧两者付出大量努力。给定部件中的任何更改可以不仅改变其自身的时间行为，而且可能使其他应用的实时属性失效。

在开发整个系统时，应用开发人员和系统集成人员必须共同努力以确保满足所有实时要求。然而，应用开发人员和系统集成人员在有效进行其自身的工作方面具有冲突的需求。

应用开发人员需要尽可能多的灵活性以使得能够开发和优化其自身的应用。应用开发人员依赖系统集成人员来确保来自不相关SWC的干扰尽可能小。系统集成人员依赖应用开发人员来满足应用级时序要求，但是确保在所有应用被集成的情况下，这些应用都仍能正常工作。系统集成人员通常努力实现尽可能静态和刚性的系统配置以确保独立的软件部件不会使独立的实时属性失效。同时满足两个角色的需求以促进有效的整体开发是巨大的挑战。

一个允许多个计算链确定性共存同时最小化干扰并保证端到端延迟的示例架构是时间触发架构。在该架构中，每个可调度实体(任务)的通信和执行是步调一致的。集成人员创建全局时间驱动的时间表，该时间表精确地控制每个任务被允许访问处理硬件的时间以及其失去对处理硬件的控制的时间。

该方法简化了独立软件部件(也被称为“软件”或“应用”)的确定性集成，同时失去了应用开发人员的灵活性。在不更改在平台级/计算机系统级上定义的平台级定义时间表的情况下，不可能改变应用到任务的分解。此外，如果任务的实现变化并且其时间预算也随之变化，则需要更改时间表，这必须由计算机系统集成人员完成。

另一方面，软件开发人员获得了软件部件不会对其任务产生负面影响的保障。

另一架构是事件驱动架构。此处，可调度实体的执行完全取决于新事件的到达时间。一旦任务的所有事件都可用，就可能允许执行该任务。由于不存在对如何执行任务以及何时执行任务的平台级控制，因此应用开发人员可以自由地在其应用内添加、删除或合并任务。这为软件开发人员提供了最大的灵活性，并且还使得能够在最佳和平均情况下但是不是最坏的情况下，最小化后续任务执行之间的延迟。然而，由于这样的任务的数量可以达到数百或数千，因此在可以真正启动该任务之前很难确定最坏情况下的延迟。每当集成了新的应用，时间行为都将改变。这还意指不清楚哪些其他部件在其他处理单元上执行而使得无法评估对并行执行的SWC的最坏情况下的影响。此外，对应用内部的任何改变都可以改变对其他软件部件的干扰的严重程度。

该方法以将问题转移到集成步骤为代价，将软件开发人员的灵活性最大化。这导致对问题的责任不明确，并且导致在多个应用集成在一起的情况下，所有应用开发人员都需要大量的调试。

无论在哪种情况下，调度实体的粒度都在任务级。由于应用包括大量任务，所以集成者必须配置和控制在应用开发人员控制下的各个方面。因此，应用结构的改变是全局可见的，并且需要广泛的分析和配置改变。

已经存在将多个任务分组到容器中并控制容器的时序方面的方法。这意指容器获得处理单元的一定份额，并且在到达边界时会被停止。例如，可以被Docker使用来控制Docker容器内应用的时序的Linux CGROUPS可以用来将包含的应用可用的CPU时间限制在最多CPU时间的一定百分比。这可以防止干扰，但是不可能针对容器内的处理提供端到端的延迟。此外，容器执行和使用的CPU/核时间的簿记与处理周期或系统中的任何特定事件不一致。这种不一致会导致处理期间不希望的中断。特别地，这些方法不处理任务执行的内部顺序。

发明内容

本发明的目的是提供一种计算机系统和方法，以在不牺牲关于计算链的端到端实时延迟要求的可预测性的情况下实现更快的开发。

利用如上面所提及的计算机系统来实现该目的，其中，根据本发明，其中，用户功能包括应用，其中，用户功能的每个应用包括多个不同的任务，其中，在应用的执行期间，执行应用的一个或更多个任务，其中，以计算链的形式以限定的序列一个接一个地执行应用，其中，计算链在其开始时接收用户功能输入数据，并且生成在计算链的执行结束时提供的用户功能输出数据，并且其中，在用户功能的执行期间，所述计算链被执行一次或若干次，其中，计算机系统提供容器，其中，计算机系统被配置成激活和去激活所述容器，使得容器是活动的或不活动的，其中，应用的所有任务被分配给容器，并且其中，每个特定应用的所有任务被分配给恰好一个特定容器，其中，在容器为活动的时间帧中，独占地保留计算机系统的一个或更多个核以用于执行所述容器的应用的任务，并且其中，计算机系统被配置成使得在容器为不活动的情况下，不能在计算机系统上执行所述容器的任务，其中，计算机系统被配置成根据应用的序列来执行容器，使得容器在紧接在其之后的容器之前被激活，并且其中，不允许计算链中的容器和紧接在其之后的容器在时间上交叠，并且其中，针对每个容器提供任务定序器，其中，在所述任务定序器的容器被激活的情况下，所述任务定序器被激活，并且其中，容器的任务定序器决定(“任务定序器决定”)：

-必须执行容器的应用的哪些任务，

-要执行的任务的序列，以及

-针对必须执行的每个任务，容器提供的必须在其上执行任务的一个核或多个核，

并且其中，计算机系统被配置成根据容器中的每个容器的任务定序器的所述任务定序器决定来执行每个容器的任务。

这创建了分层调度方法，其中容器资源使用由计算机系统/平台控制，而任务资源需求由容器内的任务定序器管理。对容器进行控制可以强制地启用或移除任务对计算资源的访问，而不需要来自任务的合作。此外，这两种方法的组合能够保证计算链的执行，即使容器调度器和任务调度器都没有整个系统的完整视图。

在当前上下文中，术语“容器”是一个抽象实体，并且在语言意义上使用，但不是在使用相同术语的技术“Docker”的意义上使用。与Docker相反，本发明允许通过对“容器”实体本身进行操作来隐式地控制所有实体(任务)的资源使用。

在容器为活动的时间段期间，一个或多个核被独占地分配给所述容器，使得分配给所述容器的应用/任务具有对所述一个或多个核的独占访问，并且可以独占地在所述一个或多个核上运行。只有所述容器的应用/任务可以在所述一个或多个核上执行。在这个时间段内，没有其他容器特别是所述其他容器的应用/任务可以在所述一个或多个核上运行。

如果活动的容器被去激活，使得所述容器变为不活动的，则所述不活动的容器，特别是分配给该容器的应用和/或任务，仍然准备运行，但是它/它们的执行(该容器的应用和/或任务的执行)被暂停。这不会改变所述容器的应用和/或任务的状态，但是确保当所述容器为活动的时独占地分配给所述容器的核的核时间不能被不活动的容器使用(特别是不能被所述不活动的容器的应用/任务使用)。

从实现侧来看，容器的去激活和激活可以通过向实现容器的进程发送信号(例如，SIGSTOP和SIGCONT)来实现。在POSIX操作系统中，这些信号被操作系统调度器截获，SIGSTOP信号迫使操作系统调度器立即停止执行目标进程内的所有任务。此外，它防止调度器执行来自特定进程的任何任务，直到接收到要继续的激活信号(例如，SIGCONT)。发送这些信号可以由平台调度器触发，例如根据其时间触发调度来触发。在这种情况下，容器相当于单个POSIX进程，并且平台调度器直接寻址容器，并且不需要知道容器内的任务。

在其他实现中，可以提供平台调度器维护或访问实现容器的所有进程的列表，并向所有包含的进程发送信号。在又一个实现中，平台调度器还可以直接维护属于容器的所有任务的列表，并直接向操作系统调度器发信号通知要激活或去激活的容器任务。最后，平台调度器还可以等同于操作系统调度器，它允许实现相同的语义，而不依赖于以这种间接的方式控制进程和线程。

该目的还利用上面所描述的方法来实现，其中，根据本发明，用户功能包括应用，其中，用户功能的每个应用包括多个不同任务，其中，在应用的执行期间，执行应用的一个或更多个任务，其中，以计算链的形式以限定的序列(defined sequence)一个接一个地执行应用，其中，计算链在其开始时接收用户功能输入数据，并且生成在计算链的执行结束时提供的用户功能输出数据，并且其中，在所述用户功能的执行期间，所述计算链被执行一次或若干次，其中，计算机系统提供容器，其中，计算机系统被配置成激活和去激活所述容器，使得容器是活动的或不活动的，其中，应用的所有任务被分配给容器，并且其中，每个特定应用的所有任务被分配给恰好一个特定容器，其中，在容器为活动的时间帧中，独占地保留计算机系统的一个或更多个核以用于执行所述容器的应用的任务，并且其中，计算机系统被配置成使得在容器为不活动的情况下，不能在计算机系统上执行所述容器的任务，其中，计算机系统被配置成根据应用的序列来执行容器，使得容器在紧接在其之后的容器之前被激活，并且其中，不允许计算链中的容器和紧接在其之后的容器在时间上交叠，并且其中，针对每个容器提供任务定序器，其中，在所述任务定序器的容器被激活的情况下，所述任务定序器被激活，并且其中，容器的任务定序器决定(“任务定序器决定”)：

-必须执行容器的应用的哪些任务，

-要执行的任务的序列(the sequence of tasks)，以及

-针对必须执行的每个任务，容器提供的必须在其上执行任务的一个核或多个核，

并且其中，计算机系统被配置成根据所述容器中的每个容器的任务定序器的所述任务定序器决定来执行每个容器的任务。

本发明简化了计算机系统特别是机动车实时计算机系统的开发和配置。因为集成人员不需要对容器内的通信和执行流进行建模，所以由集成人员来完成的配置量被最小化。这将转移到应用开发人员的责任上。

同时，可以保证计算链在最坏情况下的延迟以及应用之间不受干扰。

车辆内的软件(例如，应用)必须处理可能彼此完全独立的许多不同功能，但是仍然需要高级别的安全性。由于这些功能并不彼此依赖，因此仅需要提供特定资源来保证其针对机动车安全的可用性。

这样的独立功能的软件开发人员不再必须彼此一致。软件开发人员仅需要请求集成人员提供的资源(以容器的形式)。如果存在其他可用资源(例如，更强大的硬件和系统)，则可以在以后通过添加新容器来容易地集成其他应用。只要分配的容器所提供的资源足够，即使是应用也可以被改变。

通常，计算机系统被配置成在一个时间点仅执行一个任务，并且恰好在一个时间点在一个核上执行任务。

应用不被绑定到一个计算机部件特别是一个核，而是可以在多个计算机部件之间特别是在若干个核之间进行划分。最小的不可分割单元是任务。任务不可以分配给若干个计算机部件特别是若干个核。

任务定序器决定必须执行应用/容器的哪些任务，以及任务必须使用容器的哪些核用于其执行。任务定序器的该决定是由计算机系统特别是计算机系统的操作系统来实现的(例如，操作系统的调度器必须考虑任务定序器的决定并相应地执行任务)。

每次激活容器时，启动容器的任务定序器，其中，任务定序器优选地是容器中启动的第一个任务。例如，任务调度器由操作系统调度，特别是由计算机系统的操作系统的调度器调度。

根据本发明的容器的使用具有这样的效果，即计算机系统的配置以不允许任务在其容器不活动的时间段期间运行的方式进行调整。

容器内的任务可以由任务定序器分配给空闲核之一。

通常，计算链的第一应用从传感器接收输入数据，并且基于这些输入数据计算输出数据。所述输出数据被提供给该计算链的下一个应用，该下一个应用基于所述输入数据生成输出数据，依此类推。计算链的最后一个应用生成提供给致动器等的输出数据例如以用于操纵车辆。

通常，计算链在特定时间段内一次又一次地连续执行，并且因此，容器连续多次是活动的。可以规定任务定序器在其容器为活动的每个时间段/时间帧期间以相同的顺序执行任务，然而，通常可以规定任务定序器在容器为活动的不同时间段期间以不同的顺序执行任务。

关于所使用的术语，以下短语应具有所指示的相应含义：

·“执行应用”：执行所述应用的任务(部分或全部任务)

·“执行容器”：执行分配给所述容器的应用的任务(部分或全部任务)·“应用进行通信”：应用的一个或更多个任务进行通信，例如与平台(计算机系统)进行通信

·“容器进行通信”：分配给所述容器的应用的一个或更多个任务进行通信，例如与平台(计算机系统)进行通信。

根据本发明的计算机系统包括：

-具有一个核的一个处理器，或者

-具有两个或更多个核的一个处理器，或者

-两个或更多个处理器，其中，每个处理器包括一个或更多个核。

可以规定在一个处理器上执行例如在处理器的一个或更多个核上执行应用特别是应用的所有任务。还可以规定应用并且因此应用的任务分布在两个或更多个处理器上。

在以下描述了计算机系统及其方法的优选实现方式。

可以规定计算链被并行执行若干次，其中，计算机系统被配置成使得不同计算链的相同容器，特别是计算链的不同迭代的相同容器，在时间上不交叠。

在该上下文中，“相同”容器意指“包含”相同任务的容器。

可以规定计算机系统被配置成根据时间触发的调度来激活每个容器和/或每个计算链。

例如，在时间触发的方法中，定义的时间预算被分配给每个容器，在此该时间预算期间容器可以是活动的，其中，配置的一组核被分配给每个容器。针对链的所有不同容器，时间预算可以是相同的，但是不同的容器也可以具有不同的时间预算。对应于上面所提及的时间帧的时间预算可以在一个片中被“消耗”，或者可以将时间帧划分为两个或更多个时隙，这些时隙合在一起的持续时间等于时间预算。

此外，在时间触发的方法中，可以针对每个容器提供“周期”，这要求每个容器以所述周期周期性地结束。针对链的所有不同容器，周期可以相等，并且在这种情况下大于链的所有容器的最长时间预算。

基于这些边界，可以生成用于激活和去激活计算链和并行计算链的容器的调度，优选地使用用于生成这样的调度的离线工具来生成。

可以循环地重复例如三个容器CON1、CON2、CON3的计算链。链的每个这样的“迭代”在容器的抽象级上是相同的。因此，在每次迭代中，容器的序列是相同的，并且每个容器在相同的激活时间点被激活(在针对每次迭代从零开始的时间进行计数的情况下)。换句话说，完成计算链之后，通常会重复(若干次)，其中，计算链及其下一次迭代的容器的激活时间点和去激活时间点是“相同的”。因此，以超循环周期重复每个计算链，该超循环周期是特定容器周期的n倍，其中，n是链的容器的数量。

并行链包括容器的相同顺序，但是并行链中的激活时间点(通常还有容器的去激活时间点)可能彼此不同。此外，“并行”链在时间上偏移使得不同链的相同容器在时间上不交叠。

还可以规定计算机系统被配置成利用激活信号激活容器和/或计算链，其中，所述激活信号是事件触发的。

在这种事件触发的情况下，可以规定将优先级分配给每个容器，使得如果具有比活动的容器更高优先级的容器被激活，则去激活活动的容器，并且激活具有更高优先级的容器。在这种情况下，实际运行的容器立即被去激活，并且仅在没有具有更高优先级的容器为活动的情况下才可以继续。已经停止的容器在其原来的位置继续执行。

特别地，可以规定每个任务定序器基于任务定序器的配置来做出其任务定序器决定。

例如，配置包括容器的任务的优先级，其中，优先级被分配给每个任务。

如果每个任务定序器确定其容器内的任务的依赖性，并且特别是每次任务的执行完成时，例如基于任务定序器的配置，检查接下来可以执行哪个任务，则会是有利的。

容器彼此通信，特别地，容器n仅与容器(n-1)和容器(n+1)通信。通信优选地经由平台(计算机系统)而不是直接进行，因此容器(n-1)将其输出数据放置在平台上，容器n可以在此处访问容器n的这些输出数据。

因此，优选地，不同容器之间不存在直接通信。显然，不同容器的任务之间也不存在通信。

容器内的任务彼此通信，例如，第一任务从上一个容器“接收”输入数据，基于这些数据生成向下一个(第二)任务提供的输出。因此，第二任务可以仅在第一任务已经完成其执行时启动。

因此，优选地规定任务定序器记录哪些任务已经完成，并且每当新任务完成时，任务定序器必须更新并根据其配置例如根据模板(见下文)检查现在必须执行哪些任务。可以存在可以由任务定序器决定执行的一个以上的任务。

如上面已经提及的，可以规定按顺序执行和/或并行执行和/或在时间上至少部分交叠地执行容器的任务。

可以规定，针对每个应用，提供一个或优选地更多个用于执行任务的不同的安排(arrangements)，即所谓的“模板(template)”，其中优选地，用于应用的每个模板保证执行任务的正确顺序，并且其中，例如，配置包括一个或更多个模板，或者其中，配置是模板。

模板针对在容器内执行任务限定了有效序列。例如，模板由应用开发人员创建，并且作为文件存储在计算机系统上。当在容器中初始化应用时，任务定序器读取该文件。

根据现有技术，计算链—即任务链—保证(或限定)计算链的任务执行的正确顺序。然而，在特定任务被改变、必须在链中包括附加任务等的情况下，可能需要调整任务的整个计算链。

根据本发明，在应用中对任务进行分组，特别是在抽象级别上进行分组，其中，在容器中执行应用(准确地说是每个应用的任务)。仅在该“容器级”上，例如，通过容器调度器(还被称为“平台调度器”或“计算机系统调度器”)可以保证容器/应用的正确顺序，但是不能保证容器内任务执行的正确顺序。

这是由任务定序器完成的：每个任务定序器必须保证其容器内任务的正确执行顺序。模板的使用使得能够分析用于执行容器的任务的先验(不同)正确时间序列(＝模板)。

容器和容器内的任务定序器的组合保证了计算链的所有任务的正确执行顺序，但是平台/容器调度器不需要知道任务模板(或容器内任务的顺序)，任务定序器也不需要知道容器调度器或其他任务的模板。

总之，在容器为活动的时间帧(可以分为两个或更多个时隙)内，由任务调度器调度对应应用的任务。这些任务与其他容器中的任务无关，因此一个容器的任务和任务的执行可以与其他容器的任务无关地进行配置。

可以提供外部部件“序列审计员”，该外部部件在容器的每次执行之后接收在其中执行了任务的序列或关于所述序列的信息，并且将该序列或信息与根据其已经执行了任务的模板进行比较，以检测不正确的执行顺序。

该外部部件可以在检测到不正确的执行顺序时报告错误或者执行错误反应。

可以规定任务定序器特别是每个任务定序器被配置成：例如在任务定序器的容器开始时或在容器循环开始时选择针对所述容器所提供的模板之一，和/或在所述容器为活动的情况下在不同的模板之间进行切换。

优选地，在每次启动容器时，任务定序器选择模板。

例如，容器的任务定序器可以根据计算机系统的实际状态或者根据输入数据来选择特定模板，或者在容器的时间帧期间在模板之间进行切换。

有利的是，在可以针对容器提供至少一个任务序列适配任务的情况下，特别地，针对每个容器提供至少一个任务序列适配任务的情况下，在容器为活动的情况下执行该任务序列适配任务，其中，任务序列适配任务被配置成从计算机系统接收信息和/或接收关于计算机系统的信息，以及/或者分析数据和/或时间进度，并且其中，所述任务序列适配任务被配置成使得所述任务定序器根据来自计算机系统的信息和/或关于计算机系统的信息以及/或者根据所述数据和/或时间进度的分析结果来改变所述模板。

例如，来自计算机系统的信息和/或关于计算机系统的信息可以是实际时间，或者是在容器的活动阶段期间已经使用的时间，使得任务序列适配任务知道是否存在足够的时间来完成实际模板，并且在必要时使任务定序器改变至另一模板。

此外，可以规定计算机系统包括资源，其中，所述资源包括：

-存储器，特别是存储区域，和/或

-通信装置，例如通信信道，例如，在处理器之间和/或在核之间，和/

或

-软件，例如操作系统、一个或多个任务调度器、容器等，并且其中，在特定容器为活动的情况下，资源中的至少一些资源和/或资源的至少部分资源或所有资源被独占地分配给所述特定容器，使得在特定容器为活动的情况下，仅所述容器的应用的任务可以使用所述独占地分配的资源。

可以规定每个容器在其激活时间点接收其输入数据和/或在去激活时间点之前向计算机系统提供其输出数据。

如果容器在预定的去激活点之前发出其完成信号(仅用于TT的情况)，则使得调度器能够使用剩余时间来执行其他容器或未分配给容器的任务。

此外，可以规定计算链的容器的去激活时间点和所述计算链的直接跟随的容器的激活时间点以下述时间距离进行布置，该时间距离足以确保所有计算链的所有延迟要求并且同时使得能够有至少足够的时间以在容器之间发生通信。

还可以规定容器的时间帧例如容器的容器时隙的持续时间的总和对应于WCET(Worst-case Execution Time，最坏执行时间)或至少对应于在容器中执行的应用的任务的WCET。

在这种情况下，优选地，规定应用的任务的WCET考虑所有容器内部并行性，并且考虑应用的WCET小于所有个体任务WCET的总和。

还可以规定每个应用和/或容器与计算机系统独占地通信，并且仅在其执行的开始和结束时，特别是在其执行的每个迭代的开始和结束时与计算机系统独占地通信。

附图说明

在下文中，通过如附图所示的非限制性示例详细描述本发明。附图示出了：

图1用户功能的示例，

图2并行执行的计算链，

图3并行执行的计算链的另一示例，

图3a并行执行的计算链的又一示例，

图4第一应用的示例，

图5第二应用的示例，

图6第三应用的示例，

图7示出了其中容器时间帧被划分为两个时隙的示例，

图8容器的简单示例，

图9用于执行应用的任务的两个模板的示例，

图10模板的另一示例，以及

图11示出了图9的模板的任务如何在时间上分布以及可以在哪些核上执行所述任务。

具体实施方式

应当注意，在下文中，通过具有定义数量的应用、任务等的特定示例来描述本发明。此外，以下描述基于关于容器的执行的时间触发方法。

然而，如果没有另外说明，则以下陈述在通常情况下也是有效的，并且不限于特定数量的应用、任务等。关于特定容器的陈述，特别是与执行所述容器的任务有关的陈述，也不限于时间触发的情况，而是对于通常情况特别是对于容器的事件触发执行也是有效的。

图1示出了用户功能CUS的示例，例如所谓的“高速公路领航系统”功能，该功能使得能够在高速公路上至少部分自动地操纵车辆。该“高速公路领航系统”用户功能基于监测车辆周围和/或车辆本身的一个或更多个传感器所收集的传感器数据来控制车辆，因为用户功能基于所述传感器数据生成用于致动器(例如，用于致动器进行加速、制动、转向…)的控制数据。

通常，用户功能通过计算链CHA来实现，该计算链CHA包括一个或更多个应用特别是若干不同应用APP1、APP2、APP3或者由一个或更多个应用特别是若干不同应用APP1、APP2、APP3组成。

在所示出的示例中，计算链CHA包括三种类型的应用：

·第一应用是所谓的“预处理”应用APP1。

·第二应用是所谓的“传感器融合”应用APP2。

·第三个应用是所谓的“路径规划”应用APP3。

“预处理”应用APP1接收来自各种传感器如雷达、LIDAR、摄像装置或观察车辆环境的其他传感器的输入数据。来自传感器的输入数据是原始数据，该原始数据由应用APP1进行预处理以使得其可以由以下应用处理。

“传感器融合”应用接收由“预处理”应用APP2收集和预处理的数据，并且创建包括自由空间、交通标志以及与汽车或车辆的可能路径有关的其他规则的环境图像。

“路径规划”应用APP3接收由“传感器融合”应用APP2提供的数据并计算车辆的路径。结果即该路径规划的输出数据可以是用于控制车辆的速度和方向等的若干致动器的命令。

计算链CHA的不同应用是按顺序执行的。可以循环地执行计算链CHA。在所示出的示例中，首先执行第一应用APP1，随后执行第二应用APP2，然后执行第三应用APP3。每个应用APP2、APP3在前面的应用APP1、APP2已经完成执行之后启动其执行。

图2另外示出了可以并行执行链CHA。一旦应用例如应用APP1已经完成执行，就可以在下一个“并行”链中再次启动该应用。

如图2所示，可以规定每个应用APP1、APP2、APP3循环执行，其中，应用以循环周期CP在循环CYC期间运行。例如，循环周期为40ms。

根据本发明，在容器CON1至CON3中执行每个应用APP1至APP3，其中，每个应用被分配给恰好一个容器。

每个容器CON1至CON3具有有保证的时间预算(如图1所示，还被称为“时间帧”FRA)，在所示出的示例中，第一容器CON1(用于第一应用APP1)具有持续时间为T1E–T1S的预算，第二容器CON2(用于第二应用)具有持续时间为T2E–T2S的预算，并且第三容器CON3(用于第三应用APP3)具有持续时间为T3E–T3S的预算。

在说明书导言中详细描述了术语“容器”。简而言之，仅可以在容器为活动的时间帧期间执行应用(或者确切地说是应用的任务)。在容器为不活动的时间段期间，不允许所述容器的任务/应用在计算机系统上运行。

在所谓的“超循环”期间，依次执行计算链的不同应用，该超循环HPC是循环执行的。超循环HPC的特征在于固定的超循环周期HP。在计算链包括n个应用的情况下，超循环周期HP是循环周期的n倍，HP＝n*CP。

所示出的两个链CHA中的每个链以超循环周期HP循环地重复。

因此，在循环地重复的超循环内完成每个计算链。

通常，应用/容器接收输入数据并根据所述输入数据生成输出数据，然后将输出数据从该应用/容器提供给下一个应用/容器(其将所述输出数据用作输入数据)或提供给另一装置，例如提供给一个或更多个致动器。应用/容器彼此不直接通信，而是每个应用/容器将数据提供给计算机系统并从计算机系统接收数据。

在所示出的示例中，第一应用APP1(第一容器CON1)接收传感器数据作为输入，预处理所述传感器数据并生成输出数据，该输出数据被移交给第二应用APP2(第二容器CON2)。第二应用APP2对所述经预处理的传感器数据执行传感器融合，输出数据被第三应用APP3(第三容器CON3)用于路径规划。路径规划生成输出数据，该输出数据被移交给车辆的致动器以控制车辆的运动。

最后，除了图2之外，图3还示出了在每个链有三个应用的情况下，可以并行执行每个三个链。如从图3中可以看出的，每个特定应用在特定时间点仅可以被执行一次，使得“并行”运行的链在时间上相对彼此偏移。

图3示出了简单的示例，其中，正在“并行”运行并且仅在时间上偏移(例如，不同链的相同容器不同时运行)的所有三个计算链CHA在容器级上是相同的。因此，在所有三个链中，相同的容器具有相同的时间位置、长度、等等。

然而，还可以如图3a所示，计算链在容器级别上已经有所不同。在这种情况下，容器的顺序和循环周期(例如，在所示出的示例中为40ms)在不同的链中保持相同，但是容器相对于时间的位置，并且优选地还相对于所分配的核的位置在链与链之间可以不同。

每个应用APP1、APP2、APP3包括一个或更多个应用特定的任务或者由一个或更多个应用特定的任务组成，在相应应用的特定容器CON1、CON2、CON3中执行这些任务。

作为示例，图4示出了在容器CON1中执行的第一应用APP1(“预处理”)。应用APP1被分解为/包括若干任务，在所示出的示例中为3个任务：·任务1.1：预处理摄像装置数据

·任务1.2：预处理雷达数据

·任务1.3：预处理LIDAR数据

此处，优选地在容器CON1中并行执行任务。在执行结束时，将每个任务的输出移交给计算机系统，并且第二应用APP2/容器CON2可以访问所述输出。

作为示例，图5示出了第二应用APP2(“传感器融合”)，第二应用APP2被分解为/包括若干任务，在所示出的示例中为8个任务：

·任务2.1：预融合摄像装置数据

·任务2.2：预融合雷达数据

·任务2.3：预融合LIDAR数据

·任务2.4：地图

·任务2.5：传感器融合

·任务2.6：车道检测

·任务2.7：对象分类

·任务2.8：地标分类

通常，应用的任务可以在其容器中按顺序执行或全部并行执行(见图4)，或者如图5所示，任务中的一些任务是并行执行的，而任务中的一些任务是按顺序执行的，和/或不同任务的执行可以交叠。在所示出的情况下，任务中的一些任务生成输出，该输出被用作另一任务或应用APP2的其他任务的输入。

最后，作为示例，图6示出了第三应用APP3(“路径规划”)，第三应用APP3被分解为/包括若干任务，在所示出的示例中为4个任务：

·任务3.1：驾驶员模型

·任务3.2：预测未来对象位置

·任务3.3：运动规划

·任务3.4：计算致动器命令

并行执行前两个任务T3.1、T3.2，并且将其输出提供给第三任务T3.3，第三任务T3.3基于该输入生成用于第四任务T3.4的输出，第四任务T3.4生成致动器命令，致动器命令作为输出传输至车辆的致动器。

如已经提及的，根据本发明，规定了每个应用在所谓的“容器”中运行。第一应用APP1在第一容器CON1中运行，第二应用APP2在第二容器CON2中运行，并且第三应用APP3在第三容器CON3中运行。

“容器”是描述将资源(例如，处理器和/或操作系统的资源)独占地分配到容器为活动的时间帧期间的术语。特别地，在其上执行任务的计算机系统包括一个或更多个处理器/处理单元(CPU)，其中，每个处理器包括一个或更多个(计算)核。在容器的活动阶段期间，独占地保留特定核以用于执行相应容器的任务。

“在容器中运行的应用”意指必须执行的所述应用的一些或所有任务可以独占访问资源，特别是独占访问其容器的核，并且仅且独占地在这些资源上执行所述应用的一些或所有任务和/或仅且独占地使用这些资源来执行所述应用的一些或所有任务。

在这种背景下，图7示出了其中第二容器CON2被划分为两个时隙的示例，仅可以在这两个时隙期间执行第二应用APP2的任务。

图8示出了容器的简单示例。在该示例中，提供了包括两个处理器CPU1、CPU2的计算机系统CS。假设容器分布在两个处理器CPU1、CPU2上，而每个处理器包括在其上可以执行任务的三个核，核1、核2、核3。每个核被配置成一次执行一个任务。

如图8所示，在观察第一周期(本示例中的周期长度＝40ms)的情况下，(应当注意，所有特定时间点或持续时间的指示仅是说明性的)，“并行”执行三个计算链，其中，通过相同的阴影来标记特定链的容器：

针对所示出的“第一”链，提供了从T1S到T1E为活动的第一容器CON1。在该活动阶段期间，将资源(在该示例中为核)分配给所述第一容器CON1如下：

o将第二处理器CPU2的核核1、核2独占地分配给容器CON1；

此外，提供了第二容器CON2，其中，将资源分配如下：

o在第一时隙T2S到T2B期间独占地分配第一处理器CPU1的核1；

o在从T2R开始到T2E的第二时隙期间独占地分配第一处理器CPU1的核1和核2。

最后，提供第三容器CON3，其中，将资源分配如下：

o在从T3S开始到T3E的第一时隙/时间帧期间独占地分配CPU2的核核3。

如上面所提及的，第一应用APP1在第一容器CON1中运行。因此，在根据第一容器CON1的时隙和分配给时隙的资源(核)中执行第一应用APP1的任务。

由于第一应用APP1的任务在相应时隙中可以独占访问核，因此不存在对其他任务的干扰，例如对其他应用的任务的干扰。

显然，由于应用的任务需要特定资源和特定时间预算，因此应用的容器必须以这样的方式进行配置，即可以在每个循环期间完全执行(和完成)应用的所有任务，并且留有足够的时间将应用的输出数据移交给用户。

所示第一循环的容器CON1基于输入数据产生用于所示第二循环的容器CON2的输出数据。容器CON2产生用于在第三循环中运行的容器CON3的输出。第三循环中的容器CON3产生用于执行器的输出。

如已经描述的，所示出的示例中的容器是循环执行的，换言之，容器是以时间触发的方式调度的，并且仅根据物理时间的进展来启动和停止。在容器的启动与停止期间(在容器为活动的时间期间)，分配给所述容器的应用的任务可以独占地访问容器的限定资源。

由于应用的任务在容器中运行，因此这些任务独立于其他容器中的任务，并且不受其他容器中的任务的影响，使得可以独立配置任务。

为了完整性，应当注意，在应用的任务在其容器的活动阶段结束之前完成其执行的情况下，可以将容器去激活，使得所述容器的资源可以被其他任务使用。

在容器内，通过任务定序器来完成任务的调度。任务定序器是在容器被激活时启动的特定任务，因此任务定序器是容器中运行的第一个任务。任务定序器被配置成决定应用将如何使用容器内的任务。例如，这可以基于提供给容器的数据来完成，该数据可以反映受控设备例如车辆的特定状态。

通常，针对每个容器提供不同的所谓模板。模板是应用的任务安排以及所述任务必须如何执行的顺序。

图9示出了用于执行第二应用APP2的任务的两个模板2.1、2.2的示例。可以看出，两个模板的不同之处在于模板2.1的特定任务(任务2.3、2.4、2.7)在模板2.2中是缺失的。反过来，模板2.2包括模板2.1中缺失的任务2.9。

在该示例中，规定了任务定序器在容器的开始处决定哪个模板将用于执行应用APP2的任务。

图10示出了另一可能性。此处，实际的模板是模板2.3，并且根据该模板2.3执行任务。现在，在执行任务2.5之后，任务定序器决定切换到另一模板，此处为模板2.10。通常，这是根据特定信息，特别是来自容器外部的特定信息来完成的，任务定序器例如通过特定任务(例如，本示例中的任务2.5)来接收该特定信息，该特定任务被配置成从容器或计算链外部接收信息。

图11最后示出了模板(此处是根据图9的模板2.1的模板)的任务是如何在时间上分布的，以及在哪个核上执行任务。在图11的示例中，假设容器CON2从T2S到T2B并且再次从T2R到T2E为活动的。如该示例中所示出的，任务的执行在T2E之前即在时间点T2F处已经结束。因此，可以在时间点T2F释放容器CON2的资源，特别是核核1、核2的资源，使得例如可以从该时间点开始在这些核上执行容器外部的其他任务。

因此，每次容器运行时，例如，取决于输入数据和/或计算机系统和/或由计算机系统控制的机器的实际状态，可以调用不同的任务链。

针对计算链的平台(计算机系统)集成，可以提供以下内容，例如以集成工具的形式实现：

1)对计算链(容器之间的序列和通信)进行建模；

2)基于计算链的时序参数(容器序列)和单个容器的参数(周期、时序预算、所需处理元件数量)来生成时间触发的容器调度；

3)针对每个周期/循环，容器可以包括一个或更多个时隙。每个周期的时隙总长度等于或大于容器应用的任务的时间预算；

4)生成嵌入式软件(计算机系统的操作系统)所需的所有配置。

平台优选地提供功能以在运行期间执行以下操作：

1)例如，平台根据工具结果设置所有通信接口以实现容器之间的通信：

a.平台确保不存在未定义的通信；

b.从不将通信路径直接分配给容器内的各个任务；

2)平台提供了根据通信连接来传输数据的机制：

a.平台调整容器之间的通信，使其i)不干扰任何容器的执行，并且

ii)确保容器所需的所有数据在其每个循环的时隙开始时都可用；

b.容器的所有输出数据将最晚在循环内的最后一个时隙结束时可用；

3)基于物理时间的进展，容器调度器将处理资源分配给容器，特别是使用基于绝对物理时间的触发。这使得系统能够将执行同步到所有其他容器和外部世界：

a.为此，提供了每当达到时隙的未来开始/结束时调用容器的计时器；

b.可以在每个循环的一个或更多个时隙中执行容器。可以在循环中的任何时间点处中断容器的执行，并且可以基于容器调度器恢复容器

的执行；

c.无论何时(例如，通过计时器)调用容器调度器，容器调度器都会在其静态配置中查找下一个要停止和启动的容器以及要分配的资源；

d.容器调度器启用/禁用容器，因此仅一个容器可以访问所分配的处

理资源：

i.针对POSIX系统，这可以通过向实现容器的POSIX进程发送

SIGCONT/SIGSTOP信号来完成；

ii.可替选地，容器调度器收集进程内包括的所有任务并且将其全部设置为高/低优先级，以使所述任务不执行或者保证可以独占地访问资源；

iii.可替选地，引入了新的操作系统容器结构，其可以在不可能的操作系统中被类似地使用；

e.通过启用容器，容器内可以满足其前提条件的所有任务将继续其执

行(例如，如由上面所描述的任务定序器控制)；

f.如果进入新循环的第一时隙，则容器调度器将此用信号通知给容器。

4)平台确保容器的处理资源分配不能在容器内更改。

5)平台监督应用是否在其分配的时隙内完成。

6)如果容器未能发出完成信号，即使其在循环内的所有时间预算用尽，平台也会检测并报错，并且触发适当的反应，例如向其他ECU转发错误消息和/或重启主机或出现故障的软件部件。

7)在容器内的处理链在其时间预算用尽之前完成的情况下，剩余时间可以用于执行其他任务(特别是低紧急度后台任务)或其他容器。

8)时间触发的容器调度器还可以充当任务调度器，以将任务调度和容器调度组合在一个部件中。在这种情况下，没有被部署为容器的应用的任务将由容器调度机制直接调度。容器是循环执行的，并且在每个配置的周期完成一次。容器调度器将要在该周期期间使用的时间预算分配给容器。

每个容器严格地仅在其每个(处理)循环的开始和结束时经由平台进行通信。计算机系统提供的这些API上的传入数据以及传出数据将仅在容器循环的开始和结束阶段可用。即使任务直接使用这些API并提供数据，情况也是如此。这使得所有容器能够完全独立于其他容器的行为来完成每个循环的处理。

任务定序器对容器的任务的执行控制优选地是数据驱动的。因此，容器内任务的执行是灵活的，因为与仅可以在未来定义的时间点开始执行的时间触发的调度相反，一旦满足相应的前提条件，就可以调度任务。这提供了这样的好处，即计算链的最坏情况延迟不是每个任务的单个最坏情况时间预算的总和。通常，计算链的最坏情况时序远小于其部件的总和。

由于应用的任务的执行完全封装在其容器内，因此不需要系统集成人员的参与。另外，特定容器的配置不能使任何其他容器的时间属性无效。

为了实现容器内任务之间的通信，可以采用不同的方法。因为这些方法独立于平台配置，所以这些方法针对每个容器可以是不同的，并且适应于应用的具体需求。

优选地，任务不使用平台通信API来彼此通信。然而，所述任务可以使用平台API进行外部通信。

任务之间的所有通信与任务处理的启动和结束对准。可以从任务直接触发通信，或者可以由任务定序器间接触发通信。在第一种情况下，任务在返回之前调用write()函数。write()函数将直接使数据对其他任务可见。在第二种情况下，任务返回，调用任务定序器，然后任务定序器使数据对其他活动可见。在这种情况下，任务可以完全独立于任何其他任务进行。

任务间通信优选地与任务的启动/结束对准。除了这两个阶段之外，任务不依赖于其他任务，并且可以独立于任何其他任务进行。

在容器的循环结束时，出于记录目的可以将该循环内创建的所有内部数据发送至外部元素。为此，用于保存数据存储的存储区域被映射到容器外部的只读可访问存储区域。外部数据收集器可以用于将该存储区域映射到其自身的存储区域并收集数据以用于将来的数据回放。然后可以将数据发送到调试PC或记录到文件中。

为了控制容器内任务的顺序，可以采用不同的方法。因为这些方法独立于平台配置，所以这些方法针对每个容器可以是不同的，并且适应于应用的具体需求。

下面描述了针对该任务定序器的一种可能的实现方式。完成计算链分配给特定应用的部分所需的任务执行顺序由例如应用开发人员来配置。例如，该序列将是有向无环图(如上面所描述的模板)，并且针对每个任务限定指示在准备执行之前哪些任务必须已经完成的一组触发条件。可选地，模板可以包括关于任务的信息，例如每个任务的最小运行时间和/或最大运行时间。应用开发人员提供图作为在应用启动期间读取的活动定序器的输入文件。此外，应用开发人员向活动管理器提供实现活动的功能代码。

不同的触发条件(任务X在任务A之后，X在(A和B)之后，X在(A、B、C、D)中的N个中的2个之后等)是可能的。然而，仅(X在A之后，X在(A和B)之后)提供数据并对容器的确定性行为进行排序。

每个容器可能包含一个或更多个这样的图(还被称为模板，见上面的讨论)。这些模板是预先定义的，并且在计算机系统上例如作为人类可读文件(例如，以JSON、XML等格式)提供这些模板。在容器初始化/激活时加载这些文件。可以在运行时在这些文件之间切换。这赋予开发人员更多的自由来调整容器的运行时行为，同时仍然确保所有内容是静态定义的，这使得分析更容易。例如，可以基于容器内部条件或输入数据语义进行切换。

任务序列处理的示例

一旦开始容器的周期或任务完成，就会调用任务定序器。任务定序器基于有向无环图(模板)和例如触发条件来评估接下来需要调度哪个任务。

任务定序器将任务调度到线程池，OS调度器从线程池中获取准备好的线程并将其调度到处理单元(核)上。到处理单元的映射可以是固定的，或者可以由调度器根据容器的资源限制进行选择。

任务定序器仅能够将任务分配给在容器级定义的处理单元。这样任务可以在不依赖于其他容器的情况下进行。这使得能够在不需要考虑其他容器的行为的情况下独立地确定时间行为。因此，这可以在不必知道或考虑其他容器的存在的情况下由应用开发人员来完成。

任务定序器还提供了用于在容器的处理循环期间改变执行图的机制。针对该特殊的任务序列适配，可以在模板内对任务进行建模。

任务序列适配的任务分析条件(已经执行的任务的输出数据的语义、在该循环内已经花费的运行时间量等)，并且基于这些条件可以向任务定序器发出信号以从此时起执行不同的模板。在任务序列适配的任务完成之后，任务定序器基于新切换到的模板继续处理任务。

对活动和通信的容器内部序列的监测

确定容器的正确的时间行为可能是有利的。为此，可以使用两种机制：

1)平台内的看门狗功能，在容器上下文之外，例如在“循环开始”和“循环结束”阶段触发检查点。

a.如果没有根据容器的时序规范触发这些检查点，则引发错误。

由于该机制不能检测启动任务与结束任务之间任务的无序执行，因此为此可能需要另一机制：

2)为了检测容器内的无序执行，平台可以提供“任务序列审计员”部件。

a.在初始化容器时，将所有模板注册到“任务序列审计员”部件。

b.在循环开始时，并且每当切换模板时，将要由任务定序器执行的序列的ID报告给“活动序列审计员”部件。

c.除了“循环结束阶段”之外，还向“任务序列审计员部件”提供活动跟踪和通信跟踪。

d.“任务序列审计员”部件确定观察到的通信跟踪和活动跟踪是否与预配置的模板以及它们之间的切换一致。

e.如果发现预配置的序列和实际执行的跟踪之间存在偏差，则报告错误。

这样做的好处是，可以由外部部件监测内部应用行为，以评估容器内的执行是否满足预期行为。

任务序列审计员的示例

在初始化容器期间，可以将所有模板转发给被称为“任务序列审计员”的外部软件部件。在容器循环的每次执行结束时，向“任务序列审计员”提供任务序列跟踪。

基于可能的模板和触发条件的定义，评估任务序列跟踪是否符合预定义模板。

任务序列审计员监督容器的以下正确执行属性：

1)未执行任务

2)多次执行任务

3)任务执行序列不正确

4)模板切换的时间点不正确

5)模板之间的切换不正确

6)如果模板包括最小/最大运行时预算，则可以确定任务执行过短或过长

如果检测到这些条件中的任何条件，则报告错误。

通过容器循环的可能流量

容器的进行可能如下所示：

1)[被容器调度器允许运行]

2)使平台接口上可用的所有输入数据可用于任务

3)调用任务定序器

4)任务定序器根据其配置来调度任务

a.可以这样进行调度：

i.通过用任务定序器替换OS调度器而直接地进行调度

ii.通过将任务调度到任务池中而间接地进行调度，OS调度器从任务池中获取任务并对其进行调度

iii.或者通过在由任务定序器控制的任务开始处设置锁以使得任务能够开始其执行而间接地进行调度

5)每当任务完成时，调用任务定序器，并且基于任务状态和触发条件确定接下来可以执行哪个任务；

6)一旦执行了所有任务，就执行特殊的“循环结束”阶段，收集要发送的所有数据，并且在容器的外部接口上提供这些数据。

a.另外，可以将任务跟踪发送至任务序列审计员进行评估

7)如果时序预算没有被完全占用，则其自愿放弃控制并向平台发出完成信号；

8)[执行权限被容器调度器撤销，直到下一个循环为止]。