内容提要：此文为该连载系列的“第五”篇章，在之前的“连载（四）”中，我们已经具体在Linux中实现软件安全机制。作为此专题连载的收尾，我们将在本连载（五）中具体分析软件分区结果和评估，以及针对本专题连载的相关讨论和结论。

《功能安全环境下自适应AUTOSAR系统的评估》专题连载共分为“五个”篇章。此文为该连载系列的“第五”篇章，在之前的“连载（四）”中，我们已经具体在Linux中实现软件安全机制。作为此专题连载的收尾，我们将在本连载（五）中具体分析软件分区结果和评估，以及针对本专题连载的相关讨论和结论。

6.软件分区结果和评估

本章的目的是评估实现的软件分区机制，用于控制非安全关键任务的允许CPU时间和内存消耗。因此，确保自适应平台演示器的安全关键任务获得正确执行所需的资源。这是通过利用内核特征Cgroups来实现的，该内核特征Cgroup允许对具有与CPU资源相关的特定配置行为的任务进行分组。在本章中，检查了系统资源的使用情况，目的是评估分组机制的存在如何有助于自适应平台演示系统应用程序的正确执行。

6.1 CPU时间

如本专题连载（四）所述，CPU子集的分组被构造为只允许有限组有10%的CPU时间，而无限组被授予在资源限制内所需的所有CPU时间。为了很好地展示所有任务的资源使用情况，使用了“htop”命令，该命令已作为附加功能集成，同时准备Linux映像的构建系统——通过在包含Cgroup时应用相同的过程。“htop”命令是“top”命令的改进版本，具有更多功能，可以单独监视每个核心并识别其正在执行哪些任务。因此，可以更准确地了解每个任务消耗的CPU时间。因此，三个案例已在以下条件下执行：

1.自适应平台演示系统程序单独运行（无推断）

演示应用程序的四个软件组件（进程）由操作系统单独执行，不可能受到其他任务的干扰。如图23所示，他们使用了大约27%的CPU可用时间。（注意：CPU有两个核心，每个核心的负载分别为24.5%和31%，导致系统总负载约为27%）。

图23：自适应平台演示任务在无干扰的情况下运行

2. 自适应平台演示程序与其他任务一起运行而无需分区（容易受到干扰）

创建了15个虚拟任务来与演示应用程序一起运行，这会在处理器上创建完整的CPU负载，模拟异常行为。如下图所示，与之前的CPU消耗相比，这影响了视频适配器和预处理任务的正常CPU消耗。

图24：自适应平台演示任务在不受保护的情况下与其他任务一起运行

3. 自适应平台演示程序与分区的其他任务一起运行

现在包含15个虚拟任务，并且仅允许10%的CPU时间，从而允许视频适配器和预处理任务消耗正确执行应用程序所需的计算时间。

（注意：性能仪表显示任务使用率超过创建限制组时指定的10%，这是由于CPU调度程序(CFS)的性质造成的，在空闲可用且未使用的CPU的情况下(空闲）时间，它被分配给其他任务，尽管Cgroup应用了限制）。

图25：自适应平台演示任务与受保护的其他任务一起运行

·Kernel Shark

我们进行了进一步的调查，以评估所实施的分组机制对自适应平台演示器应用程序执行时间的影响。这是通过跟踪内核调度机制来完成的，以便更好地了解应用程序任务与其规范相关的正确执行。“Ftrace”（函数跟踪器）是一个跟踪工具，用于跟踪内核和用户空间函数，并将输出记录在/sys/kernel/debug/tracing下的文件系统目录中。然而，以文本格式读取提供小细节数据的输出可能会让人很难看到更大的图景。因此Kernelshark的开发是为了允许用户通过其GUI读取图形表示中的数据，从而提供有关进程如何交互的更大图片。

包含的一个重要子目录是“events”目录，其中包含处理器正在调度的每个任务的表示。因此，在以下示例中具体跟踪了EBA过程，它是成功执行所有计算后向测试应用程序发送制动信号的最后一个组件。下图显示了EBA进程的调度事件作为CPU 0和CPU 1正在处理的所有任务中的单个任务。在以下场景中，EBA-329可以用作始终每50ms触发一次的参考事件，正如软件开发过程中规范所指定的那样，无论正在执行什么场景。（见图26）

下图记录了CPU上持续约2.5秒的计划事件，描述了相同的先前场景，如下所示：

1.自适应平台演示程序单独运行（无推断）

虽然没有干扰，但EBA进程按照其事件触发器的指定每50毫秒调度一次。

图26：每50毫秒调度一次EBA进程

2.自适应平台演示程序在没有控制机制的情况下干扰运行

该应用程序现在沿着10个虚拟任务运行，而没有实现分组机制，这意味着虚拟任务不限于特定的CPU计算时间。因此，如图所示，EBA过程现在以不一致的方式触发，它错过了50ms的周期，并且没有按预期每50ms安排一次；与EBA-329相比。

图27：EBA进程调度周期因干扰而受到影响

3. 自适应平台演示程序在干扰控制机制的情况下运行

该应用程序现在正在运行10个虚拟任务，但控制机制处于活动状态，这意味着虚拟任务现在限制为配置时的10%的特定CPU计算时间。如下所示，EBA现在每50毫秒触发一次，并且与参考相比不会跳过任何周期。

图28：EBA进程调度周期免受干扰

由此我们得出结论，当应用程序与其他需要大量计算时间的（虚拟任务）任务一起运行时，应用程序会受到它们的很大影响，并且无法实现其预期功能。然而，通过Cgroups应用分组机制，提供了应用程序对资源的需求，并按照其规范运行。应用程序进程始终满足其循环时间，即使执行更多虚拟任务也不会发生错过。这在安全关键型应用中非常重要，其中不仅正确的值至关重要，而且满足时序要求也非常关键。

然而，授予所需的CPU时间并不能单独保证安全关键任务的正确执行，例如错误计算的传播肯定会影响应用程序的正确执行。所实现机制的进一步缺点和限制将在下面的子章节中介绍。

6.2 内存使用

正如内存控制程序所描述的，它旨在限制“非关键”任务的内存使用，以保护自适应平台演示器应用程序的内存使用。这是通过已实现的程序模拟内存泄漏场景来传达的，其中用户定义允许的内存量以及是否应执行分组。“非关键”任务是通过一个简单的程序进行模拟的，该程序需要在两分钟内分配550MB的空间。如图29中描述的以下场景，程序执行eat内存任务，但没有将它们分组到受限组中，因此演示任务现在运行时存在无法分配所需内存的风险。eat-memory任务能够分配总共550MB的空间，也可能使演示应用程序按预期运行。

图29：内存不受限制地自由分配

另一方面，当eat memory任务在分组机制的限制下运行时，它只允许分配53 MB，然后通知用户已达到限制，如图30所示。

图30：内存受到限制，并在达到限制时发出通知

内存使用限制仅出于演示目的而实施，因为演示应用程序对内存资源的要求非常低。因此，任何重大干扰实际上都不会危及演示器的预期功能。然而，在通过利用内存子集的更多属性来交换更多数据的应用程序中这些非常有用。

6.3 限制

限制非安全关键任务的内存使用和CPU消耗，并不能单独保证安全关键应用程序的正确执行。可以向安全关键任务授予所需的资源，但不给予最高优先级，这可能导致首先执行非安全关键任务。解决方法可以是使用“nice”命令，该命令提供在运行时动态更改每个任务的优先级的能力。这可以通过将低优先级分配给低关键性的任务来实现。因此，保证安全关键任务的执行优先于低关键任务。因此，对于安全关键的应用程序来说，优先级驱动的调度程序是必要的，通过它可以根据任务的重要性为任务分配优先级；与非关键任务相比，保证安全关键任务以高优先级执行。事实上，抢占式优先级调度可以提供进一步的保证，即使调度器正在执行较低优先级的任务，它也会被抢占，而调度器会执行较高优先级的任务。

然而，所提供的完全公平调度程序（CFS）不支持这些特性，因为它以比例方式执行任务；在任务之间按比例分配CPU时间。虽然CPU子集允许通过设置cpu.share属性来控制每个cgroup的份额，但它不提供精确的CPU时间限制。例如，可以允许一个组仅使用10%的CPU时间，但仍有空闲的未使用CPU（空闲）时间，受限制的组仍然可以借用。CFS的这些特性代表了在安全关键环境中实施的主要限制。

另一个限制是生成的图像无法支持实时调度。这在安全关键型应用中非常重要，因为在这些应用中，确保某些任务不仅提供恒定的CPU时间（如前所述），而且还允许固定的时间片，这一点非常重要。由于限制任务的响应时间并预测其时序行为，实时调度提供了高确定性行为，因此可以保证固定的时序要求。尽管可以通过CPU子集提供的RT可调属性来限制实时任务，但MinnowBoard硬件及其Yocto项目提供的板支持包不支持实时功能。

此外，先前实现的方法仅赋予不同任务之间资源的安全管理，同时假设每个任务执行的所有计算都是正确的。参考本专题连载（一）中的第2.3.6节，该实施并未涵盖ISO 26262所定义的第三个方面的免干扰性，该方面旨在实现信息的安全交换。然而，这使得该实现不足以保证在安全关键环境中的完全安全运行，必须实施进一步的规定以确保任务之间的信息正确交换。

7. 讨论

在本专题文章的过程中，目的是评估GNU/Linux作为安全关键环境中AUTOSAR自适应平台的潜在操作系统的适用性。基于开源开发的现有软件的重用通过GNU/Linux强大的基础社区展示了其可能的好处，它可以基于其在不同领域的广泛使用为汽车行业提供宝贵的支持。另一方面，这也带来了新的挑战，解决其在安全关键环境中实现的安全方面的问题——因为很难保证GNU/Linux满足系统开发要求，并进一步满足预期应用的安全要求。这仅仅是因为有关GNU/Linux行为规范的信息很少。在应用ISO 26262定义的软件组件资格要求时，GNU/Linux行为规范的重要性得到了进一步强调。事实上，软件资格要求恰恰要求待资格鉴定的软件组件的规范的可用性。然而，由于ISO 26262没有明确解决开源软件开发 (OSS) 的重用问题，因此需要针对GNU/Linux的资格定制程序。

在本专题连载（三）的第4.3节中，对ISO 26262第12条中定义的要求进行了匹配，目的是通过运行广泛的验证程序（利用声称的Linux符合POSIX规范）来获得GNU/Linux规范。尽管所提出的方法能够在某种程度上概述获得GNU/Linux规范的过程，但它显示出在安全关键环境中使用GNU/Linux时应考虑的重大局限性。（参见本专题连载（三）的第4.4节）

所面临的主要挑战之一是社区引入更新版本的软件——因为验证程序仅对软件组件未更改的实现有效，这意味着所执行的资格验证程序的结果仅可信于GNU/Linux的明确特定版本。然而，考虑到开源软件开发本质上发布周期短，遵循“早发布、经常发布”的方法——应该为开源软件开发找到一个通用的资格程序。这只需要很小的适应性努力就可以实现。资格认证程序在引入更新版本的软件时有效，以确保其成功重用。

放宽限制的一种可能方法是根据依赖于一组特定功能的每个应用程序的失效特征，对操作系统进行功能失效分析(FFA)。如果应用程序要提供预期的功能，这将需要确定操作系统必须提供的一组功能，以识别特定的失效点，以便采取进一步的安全措施来实现所需的安全状态。

虽然前面提到的过程旨在评估GNU/Linux在系统开发过程中的使用情况，但本专题连载的其余部分旨在在Linux中实现软件安全机制，以控制操作系统在不同关键程度的应用程序之间的资源访问。所实现的软件分区机制旨在实现不同关键性系统之间的干扰自由，以保证安全关键任务能够访问所需的CPU资源（特别是所需的计算时间和内存使用量），而不会受到其他非安全关键任务的干扰。

所实现的软件分区机制的主要优点是使用现有的内核功能，根据任务的重要性提供不同任务之间的隔离。这是通过称为Cgroups的内核功能提供的分组机制来实现的，通过该机制应用限制来允许控制和监视不同关键性任务之间的CPU资源。为了很好地演示此场景，AUTOSAR自适应平台演示程序被视为安全关键应用程序，目的是保护其所需资源免受旨在接管所有可用资源的模拟非关键任务的影响。

第6章讨论的结果表明了所实现的分区机制的效率；其中分组机制成功地保护了安全关键任务所需的资源，从而实现应用程序的预期执行——即使在非关键任务模拟的非常高的负载下也是如此。另一方面，当安全关键型应用程序不受保护时，该应用程序的循环事件触发器会出现不一致的行为，从而导致其不符合预期执行。

然而，所提供的完全公平调度程序(CFS)的特性，在寻求精确的CPU时间限制时具有显著的约束。由于任务按比例执行，因此即使受到限制，调度程序也允许任务借用空闲的未使用CPU（空闲）时间。此外，生成的图像无法支持实时调度，这在安全关键型应用中非常重要，不仅要保证为某些任务提供恒定的CPU时间，而且还允许固定的时间片。这有助于为系统创建确定性行为，从而形成更可靠的系统。

最后，该实现展示了避免干扰并实现容错系统的能力，该容错系统涉及由于执行时间分配不正确和内存泄漏而导致的故障。此外，所提出的方法也适用于自动驾驶系统等失效运行系统，其中失效安全运行是不够的，因为这些系统需要更高的鲁棒性和可用性，从而提高系统的可靠性。

8. 结论

总结本专题连载所付出的努力，我们不能简单地宣称GNU/Linux绝对适合安全关键环境，特别是在应用了ISO 26262定义的要求之后。这仅仅是因为ISO 26262没有指定实现符合性的方法。定义的要求，甚至没有涉及GNU/Linux的使用。因此，这使得实现这些安全要求的方法可供解释。因此，关于GNU/Linux对于安全关键环境的适用性的绝对声明是很难实现的。

然而，根据所提出的方法，相信可以获得证据来概述进一步所需的安全措施，以适当使用GNU/Linux。这些措施可以通过基于所获得的黑匣子行为规范进行的预执行的系统危害分析来实现，或者通过基于依赖于一组特定功能的每个应用程序的失效特征来对操作系统进行功能失效分析来实现。无论哪种情况，所提出的方法都展示了GNU/Linux规范行为的验证程序，作为实现这两种方法的重要证据。

可以通过实施保护机制来实现进一步的保证，以避免和减轻软件任何可能的危害行为。值得注意的是，所实现的分区方法证明可以避免由于执行时间分配不正确和内存泄漏而导致的故障干扰，这使得它适用于失效运行系统，有助于提高系统的健壮性和可用性，从而提高其可靠性。

综上所述，Linux的整体内核架构代表了实现完全受保护系统的一个主要缺点，因为当内核在同一地址空间中执行设备驱动程序模块时，很难对其设备驱动程序模块提供保证。因此，由于提供了更高级别的完整性，具有微内核（如QNX）的操作系统被认为更合适。

关注牛喀网，学习更多汽车科技。有兴趣的朋友，可以添加牛小喀微信：NewCarRen，加入专家社群参与讨论。

培训咨询更多信息，详询“牛小喀”微信：NewCarRen

作者：牛喀网专栏作者
牛喀网文章，未经授权不得转载！