【部分文档翻译总结 】EM中的Deterministic Execution

这篇文章大家别看了，看了反正卖软件的供应商也大概没实现。因为需求都是draft呢。

确定性

在实时系统中，确定性执行执行一般意味着：即对一组给定输入数据的计算总是在有限时间内产生一致的输出，即行为是可重现的。
在EM的语境里：calculation 可以指execution of a thread, a process, or a group of processes.
可以是事情驱动或者周期的。
需要注意到，必须将确定性和可靠性、可接触性区分。（determinism must be distinguished from other nonfunctional qualities like reliability or availability）。可靠性和可接触性通过对risk 和 failure的统计数据来研究。确定性不提供这样的数据，只评估是否会出现error的表现。

确定性的要素有很多，我们这里分为三类：

• 时间确定性：计算结果总是会在deadline前给出（时间点）
• 数据确定性：输入相同的数据和内部状态，计算结果总是相同
• 全确定性：上面两个结合。

特别强调，确定性表现对安全严格的系统十分重要，一点也不能背离这些需求。对于是否有必要添加时间和数据确定性要基于system和safety goals确定。

下面列举两个AP中对确定性有需求的use case:

• 软件锁步：实现ASIL C/D的应用。实现冗余计算和比较。需要 fully determinstic calculation。
• 已验证的软件复用：确定性子系统要在能满足其资源和性能要求的不同平台上都有相同的表现。不管有没有其他不相干的程序。例如开发和仿真环境及实车环境。这样标定和测试就不需要多次重做。

时间确定性

每次开始计算时，其结果都保证在指定的截止日期之前可用。为此，应将充足且有保证的计算资源（处理器时间、内存、服务响应时间等）分配给执行计算的软件实体。
对于非确定的best effort进程，可以要求至少有多少资源能保证其基础功能，并且可以设置最大占用资源用于监控。然而，如果要求时间确定性，资源必须在任何时间都得到保证，例如设置最小资源=最大资源。
如果违反了确定性执行的假设，例如，由于错过了最后期限，这是应用程序可检测到的错误。在非确定性的“尽力而为”子系统中，有时可以在没有专用错误管理的情况下容忍和缓解此类截止日期违规或其他与正常行为的偏差。
完全确定性行为还需要数据确定性，但在许多情况下，时间确定性就足够了。
我感觉这个是不是过于严格了，难道是专用资源？

数据确定性

对于数据确定性，每次启动计算时，其结果仅取决于输入数据。对于特定的输入数据序列，假设初始内部状态相同，则结果始终需要完全相同。
在安全上下文中验证数据确定性的常用方法是使用锁步机制，其中通过两个不同的路径同时执行，并对结果进行比较以验证一致性。硬件锁步意味着硬件具有特定的设备，以使这种双重/多次执行透明（无感？）。 软件锁步是另一种技术，允许在不需要使用专用硬件的情况下提供类似的属性。
根据安全级别以及所采用的安全概念，软件锁步可能涉及并行或顺序多次执行相同的软件，但也可能涉及运行同一算法的多个单独实现。

Full Determinism

对于完全确定性，每次开始计算，其结果在指定的截止日期之前可用，并且仅取决于输入数据，即必须保证时间和数据确定性。
非确定性行为可能源于不同的原因;例如，计算资源不足，或数据访问不协调，可能由多个线程在多个处理器内核上运行。线程访问 此类数据的顺序将影响结果，使其具有非确定性（“争用条件”）。
Fully deterministic calculation必须被设计 实现 集成，以这样一种方式： 独立于其他functions和计算的处理器负载、离散的不相干事件、资源竞争、偏离随机数等。

Deterministic Client

未来的系统需要高计算性能与高ASIL安全目标相结合。在本章中，我们指定了支持确定性多线程执行的机制，以支持高性能软件锁步解决方案。以下是其背后的一些其他理由：
• 高度自动驾驶（HAD）系统的安全目标可以达到ASIL D。 • 高性能计算（HPC）需求只能由非汽车级产品满足，例如消费电子产品（CE）、微处理器，与汽车级微控制器相比，它们具有高瞬态硬件错误率。很可能没有这样的微处理器可用于ASIL高于B，至少对于与设计相关的部件。 • 为了处理高错误率，ASIL C/D HAD 应用程序需要特定的措施，特别是软件锁步，其中执行是通过两个不同的路径冗余完成的，并且结果被比较以检测错误。 • 为了使这些冗余计算具有可比性，软件锁步需要 7.6.1.3 中定义的完全确定性计算。• 为了满足 HPC 需求，必须支持高度可预测和可靠的多线程

在内部周期中运行的两个冗余进程通过通信管理（CM）的常规接口在每个周期中获取相同的输入数据，并且由于完全确定性执行而产生（在没有错误的情况下）相同的结果。

执行管理(EM)提供确定性客户端 (DeterministicClient)API，以支持对进程内部周期、确定性工作线程池、激活时间戳和随机数的控制。在软件锁步的情况下，确定性客户端与可选的软件锁步框架进行交互，以确保冗余执行的进程具有相同的行为。确定性客户端与通信管理交互，以将数据处理与周期激活同步。

对于每个执行周期，软件锁步框架与通信管理合作同步输入数据，确保冗余执行进程的随机数和激活时间戳相同，同步执行的触发，并比较输出以检测故障（在其中一个冗余进程中，由于辐射导致的瞬态处理器内核或内存错误。)此基础结构层可以跨多个硬件实例，并且是特定于实现的。

软件锁步框架的详细信息不在自适应平台规范的范围之内。(供应商反正也不做)

AUTOSAR 自适应平台需要提供一些库函数来支持具有足够隔离的冗余确定性执行。库函数（确定性客户端）在用户进程的上下文中运行。图 7.14 考虑了如何在其中一个冗余执行的进程中使用确定性客户端。

循环进程行为由wait point API 控制。API 返回（code）以控制进程模式(register services/ service discovery/ init/ run/ terminate)… The execution is triggered by the ara::exec::DeterministicClient (see [SWS_EM_02210]), depending on a defined period or on received events.在进程中，所有输入数据在执行开始时都可以通过 ara：：com（仅限基于轮询的访问）获得，并且在一个执行周期内保持稳定。

工作负载可以部署到工作线程池 API，该 API 允许确定性地执行一组容器元素（例如数据集），这些元素由同一个可运行对象（即应用程序函数）并行处理。The runnable object 不被允许在运行时交换任何信息。例如它不访问任何可能被其他运行实体修改的数据以避免竞争。可运行的对象实例可以按任意顺序并行或按顺序物理运行。

其他确定性客户端 API 提供随机数和激活时间戳。常见的 HAD 算法使用需要随机数的粒子滤波器。 如果在工作线程池中使用，则随机数将分配给特定的容器元素，以允许确定性冗余执行。在进程到达下一个等待点之前，激活时间戳不会更改。对于确定性的冗余执行，需要同步随机数种子和时间戳。

在执行周期结束时，进程返回到等待点并等待下一次激活。

确定性客户端的 API 是标准化的，并提供实际硬件上应用程序部署的抽象。该实现是特定于供应商的，需要在集成时为使用它的每个进程单独配置。

确定性客户端类只是进程的local类。因此，目前没有预见到此 API 的安全问题。

确定性客户端的不同变体可能在软件锁步环境或独立环境中工作，以支持循环执行和确定性工作线程池。