谈ISO26262:2018软件部分的验证方法(2)

续接前文，本文谈ISO26262 Part6-6, 6-7, 6-8中相关的Verification Method。

本文提及的验证方法，在如下前一篇文章中已有描述场合，本文不再赘述。

• ​​谈ISO26262:2018软件部分的验证方法(1)​​

(1) Part 6-6 软件安全需求规约的Verification Methods

验证软件安全需求规约，其目的是验证其：

• 适合于软件开发
• 与技术安全需求的符合性和一致性
• 与系统设计的符合性
• 与软硬件接口的一致性

软件安全需求作为一类安全需求，其验证方法要求参照Part 8-6 Table 2

Walk-through, Inspection, Semi-formal verification, Formal verfication验证方法请参照前一篇文章。

说明：

采用MBD方法时，如使用模型来描述需求，则可通过执行模型的方式验证需求，即：Semi-formal verifcation

(2) Part 6-7 软件架构设计的Verification Methods

验证软件架构设计，其目的是验证其：

• 适合于软件安全需求
• 与目标环境的兼容性
• 符合设计原则

验证方法，如下图所示：

Walk-through, Inspection, Formal verification验证方法请参照前一篇文章。

(2.1) Simulation of dynamic behaviour of the design

对软件架构设计中的动态设计(dynamic behaviour)部分，进行仿真验证，往往需要利用仿真工具进行验证。例如：MBD开发场合，可利用Matlab/Simulink等工具中的仿真功能，进行仿真验证。

(2.2) Prototype generation

通过制作原型的方式，对软件架构进行有针对性的验证。
例如：对于量产项目的软件来说，其源自于的平台产品可以是一个原型，其A-Sample也可以是一个原型。

(2.3) Control Flow analysis, Data Flow analysis, Scheduling analysis

Control Flow analysis(控制流分析), Data Flow analysis(数据流分析), Scheduling analysis(调度分析)这三种验证方法，是分别对软件架构设计中的Control flow, Data flow, Scheduling进行分析。

根据分析的目的不同，在功能安全场合，一般可分为：

(2.3.1) 验证安全机制的充分性：应用在Safety Analysis中

Safety Analysis分析的步骤：

1) 识别Data Flow, Control Flow, Scheduling中的失效模式
2) 分析该失效的影响 --> 是否对安全需求有影响
3) 有影响的场合，是否有安全机制来Detect该失效？
4) 有影响的场合，是否有安全机制来Handle该失效(如：进入安全状态）?
5) 如果安全机制有缺失，或不足，则需要Update软件架构设计

"1）识别失效模式"可采用HAZOP的关键字方法，如：

下图所示的数据流图中，Signal A1, A2, ..., An的数据失效模式可包括：

• After / Late : Signal too late or out of sequence
• Before / Early : Signal too early or out of sequence
• No : No signal
• More ：Signal value exceeds permitted range
• Less ：Signal value falls bellows the permitted range

[注：如上示例内容参考自ISO26262:2018 Part-6 附录E]

(2.3.2) 软件组件间是否存在级联失效：应用在软件组件独立性分析中

软件组件的独立性分析，是验证软件组件之间的独立性要求是否得到了充分的保证、具备不同安全等级的软件组件是否能够共存。在独立性分析时，包括有软件组件之间是否有级联失效(cascading failure)。

软件架构设计中的Control flow, Data flow, Scheduling都提示了软件组件之间的交互关系，通过对这些交互关系的分析，能分析组件与组件之间是否存在级联失效。

示例：

下图所示的调度图中，可以看出“QM software component"发生失效(execution time exceeds specified limits)场合，会影响到“ASIL software component”，也就是存在有级联失效。

[注：如上示例内容参考自ISO26262:2018 Part-6 附录E]

(3) Part 6-8 软件单元设计的Verification Methods

软件单元设计的验证目的及方法，是在Part 6-9中进行的阐述。

验证软件单元设计，其目的是验证其：

• 与软件需求及软件架构设计的符合性
• 与软硬件接口的符合性
• 有效的使用了资源（如：CPU, memory）
• 软件架构设计中的安全措施被正确的实施了

验证方法，可参照下的黄色背景部分，验证方法的说明请参照前一篇文章。

说明：

• 上表是"软件单元设计"+“软件单元”的验证方法，黄色背景部分是适用于"软件单元设计"的验证方法。
• "1i static analysis based on abstract interpretation": MBD开发场合，使用静态分析工具对模型进行分析，其中如果包括分析“运行时错误”，就是这个方法的应用。

推荐阅读：

• ​​​谈ISO26262:2018软件部分的验证方法(1)​​
• ​​ISO26262软件部分的测试: (1) 软件单元测试​​
• ​​ISO26262软件部分的测试: (2) 软件集成测试​​
• ​​ISO26262软件部分的测试: (3) 嵌入式软件测试​​
• 更多精彩文章请参照本公众号的菜单
• ​​上海先起之仨人谈起公众号文章合集下载！​​

文章转载自公众号：仨人谈起