在AUTOSAR中，什么使BSW成为ASIL BSW？

Question

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

例如，我主要讨论的是COM RTE操作系统模块。

是否有一些额外的安全选项？

或者模块是以某种安全的方式重新设计的？

Answer 1

你的问题有不同的方面。

(几乎与你想问的内容无关。)

qualified?

• When组件是否需要符合ASIL的要求？

• 我如何判断我所查看的代码是否具有/需要ASIL ？

关于1：

• To a large extend quality
  • by reviews
  • 由测试状态衡量，包括测试深度、测试覆盖率、兼容性类测试设计和由静态分析代码结果(例如汽车行业中的MISRA )衡量的
  • 处于非常严格的测试结果范围内

所有that的过程质量可追溯性(

• • ，如ASPICE processes
  • documentation
  • requirement engineering
  • version control
  • archiving
  • change management
  • system architecture/design
  • bidirectional
    • )，但不可忽视

关于2：

• 如果产品安全体系结构需要一个组件，则它需要ASIL资格；
• 与ASIL相关的功能链中的所有组件都需要该资格；让其中一个合格(即使比必要的级别更高)不足以满足两个相同组件的安全性要求(
• )，在两个相似的产品中执行相同的工作，一个可能需要，另一个不需要；因为安全体系结构可能涵盖该特定组件的相关安全方面-或者产品(或功能链)中的不同组件。

关于3：

不。请参见上面的。

相同的代码可能需要它，也可能不需要，这取决于架构决策。

相同的代码可能有也可能没有，这取决于所涉及的开发过程是否足够严格。

顺便说一下，我看不出AUTOSAR与此有什么关系。虽然ASIL和AUTOSAR经常，但并非总是，是亲密的邻居。

Answer 2

RTE不是BSW模块；它是生成的粘合代码。鉴定RTE的方法是鉴定它的生成器。

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

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

Answer 3

操作系统和RTE实际上是AUTOSAR的主要组成部分，以提供一个安全的环境。OS具有通过不同的OsApplication和OsTasks来分离QM和ASIL应用程序的手段，每个OsApplication和/或OsTasks具有相应的MPU设置，其在上下文切换上被重新配置。

RTE是粘合代码，它还包括实际的任务主体，因为Runnables是由RteEventToTaskMapping和RteBswEventToTaskMappings添加到任务中的。RTE生成器还生成SWCs RTE接口，包括例如用于在SWC S/R端口上读/写E2E保护信号的E2E变压器生成。此外，如果从不同的安全上下文调用C/S接口，则应将其解耦(例如，ASIL SWC调用QM SWC C/S接口)。

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

通常，WDGM (或扩展)也用于作为安全概念的一部分的Runnable Alive/逻辑监督。

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

请考虑以下方案: MonitorA reports failure DemEvent_A (MonitorInternalDebouncing) MonitorB reports failure DemEvent_B (DemInternal取消弹跳) MonitorC reports failure DemEvent_C (DemInternal取消弹跳)

// 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上下文中执行(例如，操作系统“可信功能”vs“非可信功能”)。这允许在ASIL上下文中调用它们，而无需切换OsAppl/OsTask上下文，这可能会占用大量的运行时。