对于verification criteria and verification method， 很多人看到verification想当然直接归纳为测试部分，但是功能安全开发中需求的验证方法以及验证标准，理解稍有不同，以下举例具体到车载信息娱乐系统开发场景。

首先，

1. 核心概念解析

我们需要理解几个关键术语：

· 功能安全：指不存在由电气/电子系统的功能异常行为引起的，导致不合理的风险。
· FuSa 开发：指遵循 ISO 26262 标准的一套系统化的工程开发流程，旨在确保汽车电子电气系统的功能安全。
· 需求：在 FuSa 语境下，这不仅仅是“用户想要什么”，而是包含了从顶层《安全目标》派生出的《技术安全需求》、《硬件安全需求》和《软件安全需求》等一套层级化的、精确的需求体系。
· 验证：“我们是否在正确地构建产品？” 这里特指对需求本身的检查，确保需求是正确、完整、一致、可测试和可行的。它发生在设计和开发阶段之初。
  · 注意：不要与“确认”混淆。“确认”是“我们构建的是正确的产品吗？”，是在产品开发完成后，检查最终产品是否满足了顶层的安全目标。

所以，“功能安全开发中需求的验证方法” 指的是一套系统化的技术和活动，用于检查和评估在 FuSa 过程中定义的各种安全需求（尤其是技术安全需求和软件安全需求）的质量，以确保它们为后续的设计、实现和测试奠定了坚实的基础。

2. 具体的需求验证方法

ISO 26262-8 标准中详细描述了这些方法。根据不同的asil 等级目标要求，推荐不同的方法，以下是几种最核心和常用的需求验证方法：

1. 评审

这是最基本、最常用也最有效的方法。通过同行专家会议的形式，系统性地检查需求文档。

· 如何进行：组织一个评审小组，成员包括系统工程师、软件工程师、硬件工程师、安全经理、测试工程师等。
· 检查内容：
  · 正确性：需求是否准确反映了安全目标？技术上是否正确？
  · 完整性：是否覆盖了所有相关的故障模式？是否所有接口都定义了？是否考虑了所有运行模式？
  · 一致性：需求之间是否存在矛盾？术语是否统一？
  · 可验证性：需求是否可以被测试或分析？是否有明确的通过/失败标准？
  · 可理解性：需求描述是否清晰，没有二义性？
· 输出：评审记录、问题报告、需求变更请求。

2. 检查

比评审更正式、更严格，通常由非作者本人逐行审查需求文档，按照预定义的检查表进行。

· 特点：通常是个人活动，侧重于发现文档中的缺陷，如语法错误、格式问题、不符合模板要求等。

3. 演练

一种不太正式的评审，由作者主导，向评审小组讲解需求，以收集反馈。目的是在早期发现高层次的理解错误和逻辑问题。

4. 形式化验证

这是一种基于数学的、非常严格的验证方法，特别适用于安全关键性高的需求。

· 如何进行：使用形式化建模语言（如时限自动机、状态机）对系统或软件的需求进行建模，然后通过数学工具（模型检查器、定理证明器）来验证需求属性是否满足。
· 应用场景：验证复杂的逻辑或时序需求，例如“在A事件发生后，必须在X毫秒内做出B响应，并且在Y毫秒内永远不能出现C状态”。
· 工具示例：Simulink Design Verifier, ANSYS SCADE。

5. 原型开发与仿真

通过快速构建一个可运行的模型或原型，来验证需求的可行性和正确性。

· 应用场景：验证人机交互相关的安全需求（如警告信息的显示时长、音量），或验证复杂的算法需求。

3. 在车载 IVI 开发中的具体应用和实例

车载 IVI 系统传统上被认为是“低ASIL等级（QM或ASIL A）”的部件。但随着其功能越来越复杂（如与ADAS系统的交互、360环视、驾驶员监控等），其中也包含了需要更高ASIL等级（如ASIL B）的安全相关功能。

假设一个安全目标： “防止在车辆行驶过程中，中控显示屏出现非预期的、持续性的黑屏或卡死，导致驾驶员无法查看关键信息（如倒车影像、安全警告）。”

从这个安全目标，我们可以派生出一个技术安全需求：

· TSR: “IVI系统的主应用处理器必须配备看门狗机制。软件健康监控任务必须周期性地（每100ms±10ms）喂狗。如果看门狗在300ms内未被喂食，系统必须执行安全状态转换：在50ms内重启显示驱动模块，并确保在1秒内恢复基本显示功能（如倒车影像、速度、警告灯）。”

如何验证这个TSR需求？

1. 评审/检查/演练：
   · 正确性：评审专家会问：看门狗是解决此类问题的正确方案吗？
   · 完整性：需求是否定义了正常周期（100ms）、超时时间（300ms）、响应时间（50ms, 1s）？是否定义了安全状态（重启驱动模块，恢复基本显示）？
   · 一致性：100ms的周期与软件架构中其他任务的周期是否协调？会不会导致CPU过载？
   · 可验证性：这个需求可以被测试吗？答案是肯定的。可以通过注入故障（如杀死健康监控任务）来验证看门狗是否在300ms后触发，以及显示功能是否在1秒内恢复。
   · 可行性：软件架构师会评估：在50ms内重启显示驱动模块，技术上是否可行？
2. 形式化验证：
   · 可以为此需求建立一个形式化模型。可以定义属性：“永远不能”出现“看门狗超时（>300ms未喂狗）且系统未在50ms内启动重启流程”的状态。然后用模型检查器自动地遍历所有可能的状态，验证这个属性是否永远成立。
 

对于验证准则，

与“验证方法”类似，“需求的验证准则”在ISO 26262标准中也有关键的集中定义。

需求的验证准则主要规定在 ISO 26262-8 中；

在ISO 26262的语境中，“验证准则”指的是用于判断需求质量的一套属性或标准。这些准则确保了需求本身是高质量的，从而为后续的设计和测试打下坚实的基础。

验证准则的具体属性（内容）

根据 ISO 26262-8:2018, 对安全需求的验证应至少考虑以下准则（属性）：

• Accuracy 正确性 需求是否准确地描述了预期的功能或约束？是否与技术真相一致？
• Completeness 完整性 需求是否完整？是否覆盖了所有相关的操作模式、故障情况和系统接口？
• Consistency 一致性 需求内部及各需求之间是否存在矛盾？（例如，逻辑冲突、术语冲突）。
• Feasibility 可行性 在给定的技术、成本和时间约束下，需求是否可以被实现？
• Bidirectionaltraceability 双向可追溯性 需求是否能够向前追溯到其来源（如更高层的需求），并向后追溯到其实现和验证（如设计、测试）？
• Understandability 可理解性 需求是否被清晰、明确地陈述，没有歧义？
• Verifiability/Testability 可验证性/可测试性 是否可以通过一些客观的方法（如测试、分析、检查）来验证需求是否被满足？这是非常关键的一条。
• Compliance to therequirements specificationtemplate 符合需求规范模板 需求的编写是否符合预先定义的组织模板或结构？

在车载IVI开发中的实践

当您为IVI系统编写一个安全需求时，例如：

“当系统检测到主应用程序处理器核心负载率超过95%持续2秒时，应在100ms内关闭非关键娱乐功能（如视频播放），并确保关键功能（如倒车影像、警告提示）的显示帧率不低于15fps。”

您需要用上述准则来验证这个需求本身：

· 可验证性？ 可以测试。可以注入高负载，并测量响应时间和帧率。

· 无歧义？ 明确定义了“非关键娱乐功能”和“关键功能”。

· 一致性？ 与系统架构中关于任务优先级的设计是否一致？

· 可行性？ 软件架构师需要评估在100ms内完成功能降级是否可行。

总而言之，“需求的验证准则”目标是确保需求是正确、完整、一致和可测试的。