Qt Group：验证安全设计——架构检查在免于干扰（FFI）中的应用

2025年3月18日，在第六届软件定义汽车论坛暨AUTOSAR中国日上，Qt Group中国资深解决方案工程师张帆分享道，免于干扰（Freedom from Interference, FFI）是指在混合关键系统中，确保低安全级别的模块故障不会影响高安全级别模块的功能。依据ISO 26262标准定义了导致连锁故障的主要类别，包括与时间执行相关的错误、内存相关错误和信息交换相关错误。

静态分析工具可用于验证代码实现与架构设计的一致性，帮助检测潜在的干扰问题。在开发早期引入静态扫描工具（如每日构建或代码提交时），可以有效避免内存和信息交换错误。

架构验证技术基于三个关键要素：架构模型、源代码中的依赖关系，以及源代码与架构模型的映射。通过使用静态代码扫描工具，可以绘制出架构图，表示不同模块及其依赖关系。源代码的依赖关系通过编译自动生成，并在编译过程中形成中间表示形式。通过在静态代码扫描工具中使用映射功能，可以将源代码模块与架构图上的模块对应起来，从而检查源代码是否符合架构设计的依赖关系。检查过程分为两步：首先检查源代码模型与架构模型的依赖关系是否匹配，其次扫描架构模型中未在源代码中实现的依赖关系。最终结果通过绿色、红色和黄色箭头表示符合、不符合及未实现但必要的依赖关系。

以下为演讲内容整理：

导言

当开发涉及安全强相关项目时，系统安全运行的核心前提在于构建一个极为严谨的架构设计。此架构设计需具备安全性，以确保嵌入式设备能安全运作。在此背景下，ISO 26262标准提出了相应的规范，架构设计必须实现“免于干扰”（Freedom From Interference）的技术。

为了验证该技术，需采用静态分析方法。在静态分析中，可以对代码与架构的一致性进行验证。验证结果可通过报告形式展现，例如，在内部进行审计时，或在进行ISO 26262验证时，可提交静态分析结果，以证明系统具备免疫干扰的能力。

在开发与安全相关的系统时，常会遇到以下两种情况。首先，一个软件项目中会包含多个功能模块，但这些模块的安全级别并不一致。例如，有的模块与驾驶安全紧密相关，而另一些则可能与显示功能或车内灯光控制相关。这些模块的安全级别和开发要求存在显著差异。如ADAS或自适应巡航等与强安全相关的模块，其开发要求不可能与车内灯光控制等弱安全相关模块的要求相同。这就提出了一个要求：弱安全相关模块的故障不应影响强安全相关模块的正常运行，更不能导致整个系统发生故障。

ISO 26262标准定义了引发连锁故障的各类故障类别。一是与时间和执行相关的故障，例如运行时的阻塞现象，如死锁或活锁等。二是与内存相关的故障，如内存溢出或下溢。三是与信息相关的错误，包括数据延迟、丢失等问题。为有效避免这些内存或信息交换方面的错误，我们可以采用静态扫描的方法。在这方面，有一个被广泛认可的最佳实践，即在开发早期阶段就引入静态代码扫描工具，以便从项目初期就识别并纠正潜在问题。

在V模型开发流程中，在架构定义完成后，进入软件开发及单元实施阶段时，需引入静态分析工具以及时对软件架构进行验证。例如，在CI流程中，无论是日常构建还是代码提交时，都应进行架构验证，以确保代码实现与架构设计的一致性。

架构检查

架构验证的前提包含三个关键要素，只要静态扫描工具中具备这三个要素，即可进行架构验证。第一个要素是架构模型。

通常我们使用EA工具，或采用Word文档等形式来设计架构。为了实现架构验证，我们需要在静态代码扫描工具中绘制架构图。下图右侧是所绘制的架构图，该架构图包含了多个层级中的模块及这些模块之间的依赖关系。依赖关系的箭头具有不同的颜色和定义：黑色箭头表示各种依赖关系均被允许；蓝色箭头特定用于表示仅允许的函数调用关系；粉色箭头则用于表示涉及全局变量的依赖关系等等。

在具备第一个要素的基础上，我们还需要第二个要素，即在源代码中明确表达依赖关系。通常，源代码间的依赖关系是通过编译过程自动生成的。静态代码扫描工具内置编译器，能够在编译阶段将源代码转换为中间表示形式，从而自然地形成源代码间的依赖关系图。

第三个要素是将前两个要素进行对应，即将源代码映射到架构模型上，这一步可通过静态代码扫描工具中的mapping视图实现。我们可以直接将扫描得出的源代码模块与架构图中的模块进行对应，逐一将模块拖动至架构图上，直至所有模块完成映射。此时，工具即可识别哪些源代码对应于哪些架构模块。

凭借架构图上的依赖关系与源代码中的依赖关系，我们的工具能够检查源代码是否符合架构设计中的依赖关系要求。这一检查过程大致分为两个步骤。第一步，工具会先检查源代码模型中的依赖关系，并将其与架构模型中的依赖关系进行比对。比对结果无非两种：符合与不符合，分别通过绿色和红色的箭头进行标识。第二步，工具会在架构模型中继续扫描剩余的依赖关系，以识别那些没有对应源代码的依赖关系。

在此阶段，我们需进行判断。如果某依赖关系为可选，则将其忽略；如果其为必要依赖关系但源代码中未实现，则通过黄色虚线箭头进行标识。下图右侧为检查结果的示意图，展示了三种可能的结果，分别由三种不同颜色的箭头表示。

针对我们的示例项目，我们进行了逐步的比对。比对的起点是main函数沿着调用链逐步深入，每到达一个模块的调用关系时，都与架构图进行逐一比对。直至遍历了所有的调用关系后，我们得到了一个结果图。

进行分区架构检查验证安全设计

ISO 26262标准中明确界定了不同的ASIL等级，其中，与安全无关的模块被归类为QM模块。ASIL等级依据安全程度的不同，细分为A至D共四个层级。因此，在整体软件系统中，我们能够为每个模块根据其ASIL等级进行明确标注。完成标注工作后，我们可以对这些模块实施ASIL分区。若某模块与安全无直接关联，则将其归入QM分区；其余模块则根据其ASIL等级，分别归入ASIL A至D的相应分区之中。

值得注意的是，我们不仅仅局限于上述五种分区，还可以根据实际需求增加额外的分区。例如，当同一接口被不同模块调用时，我们可以将这些模块分配到不同的分区中，以便更有效地追踪模块的调用关系。

完成分区定义后，我们可以构建出一个分区架构的架构端。这一架构端与我们的架构图相似，但其上的元素不再是具体的模块，而是我们定义的分区。以示例项目为例，我们将其分为了与安全相关的A、B、D三个分区，以及一个与安全无关的QM分区，共计四个分区。这些分区之间的关系体现为从A到B，再从B到D的函数调用链。

架构验证的结果如图所示，其中从B到D的调用关系符合我们的定义。然而，A到B之间的关系却以双向红色箭头表示，存在违规情况。虽然A到B的函数调用是允许的，但在此场景下，A到B的交互还包括了对全局变量的使用，这并不在我们的定义范围之内。因此，A到B的这种调用方式被视为违规。

同样，B到A的函数调用也明显不在我们的分区架构之内，故被视为违规。通过分析这样的结果，我们能够识别出系统中与分区架构相违背的几处关键点，并据此作出相应的处理决策。我们需要判断是应该修改架构图以适应当前的代码实现，还是应该对源代码进行调整以符合架构要求。

我们的分区架构检查不仅限于对源代码的审查，该技术同样可用于检验原始架构图。通过对比分区架构图与原始架构图，我们能够发现原始架构图中存在的不合理之处。例如，在分区架构图中，我们仅允许B到D的函数调用，而原始架构图则允许了所有类型的调用关系。

检查的完整性

或许有人会问，是否仅凭静态代码扫描工具进行架构验证，就能充分满足ISO 26262对于抗干扰性的要求。显然，答案是否定的。因为静态代码分析工具本身存在局限性。

首先，静态分析往往倾向于过度估计潜在的问题，特别是在处理指针和数字索引时。由于静态分析工具仅能基于扫描所得的上下文信息进行大致的评估，预测可能在哪些指针或数组中出现问题，但无法做出精确判断。因此，对于静态代码分析工具的结果，需要工程师结合具体的上下文来判断其是否真正构成问题。

其次，静态代码分析工具的主要目标是确保源码的正确性，对于运行时出现的故障，特别是与硬件相关的故障或工具链问题，它无法做出正确的判断。因此，我们仍需结合动态测试来发现这些问题。此外，进行架构分析的前提是，我们的源码必须是精确且严谨的，不能包含未定义的行为或未指定的行为。

关于行为的不确定性问题，MISRA规则中亦存在诸多相关规定。因此，我们可以先运用MISRA规则解决此类问题，随后再进行精确的架构验证与扫描。

静态分析工具在解决与免于干扰相关的其他问题上也发挥着重要作用。例如，它可以验证对特定模块的访问情况，或确认入口函数是否被调用，这些验证结果均可反映在具体的分区架构图或架构模型上，并通过与代码的比对来得出精确结论。

总体而言，我们探讨了免于干扰的必要性，并通过分区架构检查技术，实现了手动设定安全级别并向分区架构转换的过程。值得一提的是，该过程可完全自动化实施。若已采用架构验证手段，则仅需少数几步操作，即可完成分区架构的设置与验证工作。

（以上内容来自Qt Group中国资深解决方案工程师张帆于2025年3月18日-19日在第六届软件定义汽车论坛暨AUTOSAR中国日发表的《验证安全设计：架构检查在免于干扰（FFI）中的应用》主题演讲。）