是什么让 BSW 成为 AUTOSAR 中的 ASIL BSW？

如何解决是什么让 BSW 成为 AUTOSAR 中的 ASIL BSW？

在 Autosar 中，什么决定 BSW 模块是否符合 ASIL 标准？

例如，我主要谈论的是 COM RTE OS 模块。

是否有一些额外的安全选项？
还是以某种安全的方式重新设计了模块？

解决方法

你的问题有不同的方面。
（几乎与你想问的无关。）

要获得 ASIL 认证的组件有哪些要求？
组件何时需要通过 ASIL 认证？
如何判断我查看的代码是否具有/需要 ASIL 资格？

关于1：

提高代码质量
- 根据评论衡量
- 按测试状态衡量，包括测试深度、测试覆盖率、兼容性类测试设计
- 根据静态分析代码结果（例如汽车行业中的 MISRA）衡量，处于非常严格的范围内
但不可忽视的工艺质量
- 例如ASPICE 流程
- 文档
- 需求工程
- 版本控制
- 归档
- 变更管理
- 系统架构/设计
- 所有这些的双向可追溯性

关于2：

如果产品安全架构需要，组件需要 ASIL 认证
ASIL 相关功能链中的所有组件都需要资格认证；让其中一个合格（甚至比必要的水平更高）是不够的
两个相同的组件，在两个相似的产品中做同样的工作，一个可能需要它，另一个不需要；因为安全架构可能涵盖与特定组件相关的安全方面 - 或产品（或功能链）中的不同组件

关于3：
不是。见上文。
相同的代码是否需要它，取决于架构决策。
相同的代码可以有也可以没有，这取决于所涉及的开发过程是否足够严格。

顺便说一下，我不明白 AUTOSAR 与此有何相关性。尽管 ASIL 和 AUTOSAR 经常（但并非总是）是近邻。

RTE 不是 BSW 模块；它是生成的胶水代码。验证 RTE 的方法是验证其生成器。

除此之外，@Yunnosch 的回答可以应用于 SwC 和 BSWM。

在 AUTOSAR 建模中，可以声明（但未确定）组件/模块的安全级别。如果您尝试将非 ASIL 模块分配给受信任的分区，配置器可能会引发错误。

OS 和 RTE 实际上是 AUTOSAR 的主要部分，用于提供安全环境。操作系统有办法通过不同的 OsApplication 和 OsTasks 分离 QM 和 ASIL 应用程序，并根据每个 OsApplication 和/或 OsTasks 的 MPU 设置，这些设置在上下文切换时重新配置。

RTE 是胶水代码，它也包括实际的任务主体，因为 Runnable 是通过 RteEventToTaskMapping 和 RteBswEventToTaskMappings 添加到任务中的。 RTE 生成器还生成 SWCs RTE 接口，包括例如用于在 SWC S/R 端口上读/写的 E2E 保护信号的 E2E 变压器生成。如果从不同的安全上下文（例如 ASIL SWC 调用 QM SWC C/S 接口）调用，C/S 接口也应该解耦。

COM 不一定需要是 ASIL，但如果使用 COM 超时监控，则可能需要。但这也可以通过 E2E 保护和在 ASIL 上下文中运行的 ASIL-SWC 来完成。但也要考虑，如果 COM 通过 RTE 调用 ASIL-SWC 中的回调处理程序。

通常，还会使用 WDGM（或扩展），用于将 Runnable Alive/Logical-supervision 作为安全概念的一部分。

不幸的是，Dem/FiM 组合从未以实际处理 DemEvent 报告和 FunctionInhibition 映射以用于安全处理的方式指定，以便将功能带入安全状态。我不确定，这是否仍然可以更改。缺点是，出于安全原因，一些 AUTOSAR 堆栈供应商提供自己的，一些 OEM 有一些特定的模块，和/或公司必须找到自己的方式/组件，单独处理这个，添加许多不兼容的解决方案等等资源使用。

在此考虑以下场景： MonitorA 报告失败 DemEvent_A (MonitorInternalDebouncing) MonitorB 报告失败 DemEvent_B (DemInternal Debouncing) MonitorC 报告失败 DemEvent_C (DemInternal Debouncing)

// DemEvent to FiM mapping,meaning,which functions are impacted
// If DemEvent is active,Functions are not allowed to run -> safe-mode
DemEvent_A --> FiM_FuncA,FiM_FuncB
DemEvent_B --> FiM_FuncA
DemEvent_C --> FiM_FuncC

在上面的示例中，在 DemEvent_A 或 DemEvent_B 处于活动状态的情况下，不允许运行 FuncA。如果 DemEvent_A 处于活动状态，则不允许使用 FuncB，但即使在 DemEvent_B 处于活动状态时仍然允许。 FuncC 只依赖于 DemEvent_C。

这样，一个函数（在 SWC_A、SWC_B、SWC_C 中实现）可以通过查询 FiM 来检查故障处理：

SWC_A：

void SWC_A_MainFunction(void) {
    boolean bPerm = FALSE;
    uint8   FuncAStat;
    FiM_GetFunctionPermission(FiM_FuncA,&bPerm);
    if (TRUE == bPerm) {
        // FuncA allowed to run
        FuncAStat = FUNCA_RUNNING;
        Rte_Write_pFuncAStat_Status(FuncAStat);
    } else {
        // FuncA not allowed to run
        Rte_Invalidate_pOutPort();
        FuncAStat = FUNCA_MALFUNCTION;
        Rte_Write_pFuncAStat_Status(FuncAStat);
    }
}

使所有组件 ASIL 通常没有意义，但至少，它们应该符合 FFI（干扰自由）的资格，这可以确保它们例如只访问他们设计的记忆。然后，这些组件也可以在 ASIL 上下文中执行（例如操作系统“可信功能”与“非可信功能”）。这允许在 ASIL 上下文中调用它们，而无需切换 OsAppl/OsTask 上下文，这可能会占用大量运行时间。