汽车功能安全 -- Part6（2）

目录

1.软件单元设计

1.1 输入 

1.2 实现需要注意

1.3 成果物

2.软件单元验证

2.1 目标

2.2 输入

2.3执行单元验证方法

2.3成果物

3 软件集成验证

---

书接上回，今天继续聊：

-- 软件单元设计和实现（6-8）

-- 软件单元验证（6-9）

-- 软件集成和验证（6-10）

-- 嵌入式软件测试（6-11

1.软件单元设计

        单元设计，很明显就是对功能函数进行详细设计。代码的实现既可以手写也可以通过软件自动生成，这里就有个疑问，在做功能安全认证时是否需要考虑工具的认证？

        在单元设计时，功能安全和非功能安全都需要实现。

1.1 输入 

        在进行单元设计时，需要输入文件有：

• 软件开发环境
• HSI
• 软件架构Spec
• 软件功能安全需求Spec
• 配置数据
• 标定数据
• 失效分析报告
• 功能安全分析报告
• 非功能安全的spec

1.2 实现需要注意

        首先单元设计时需要注意子程序和函数是否正确执行，接口要保持一致性，在数据流和控制流出现错误时该如何处理。

        其次，指针的有限制使用，这一点其实在代码中很难把握这个度。 

1.3 成果物

• 软件详细设计Spec
• 软件单元代码或模型

2.软件单元验证

2.1 目标

        因为软件测试一直是我比较薄弱的地方，所以来详细看下文档

        软件单元验证目标如下

1. 为单元设计是否满足软件需求提供证据
2. 基于功能安全分析来验证设计的功能安全措施是否能满足功能安全要求
3. 为ASIL等级评定提供证据
4. 证明软件单元既不包含不期望的功能，也不包含不期望的功能安全--即不满足功能要求，也不满足功能安全

        总体来讲，一个好的单元测试，需要测试功能，也要测试功能安全需求；在设计测试用例时，给定不同输入，比对实际结果和预期结果。

2.2 输入

• HSI
• 软件架构设计Spec
• 软件单元设计Spec
• 软件单元设计代码/模型
• 标定数据
• 配置数据
• 功能安全分析报告
• 软件开发环境文档

2.3执行单元验证方法

        需要注意pair-programming，结对编程，传统意义上应该是两个都比较有经验的工程师，常见形式：一个负责详设，一个负责代码；或者一个负责详设代码，一个负责review；现在很多公司的老带新，不算结对编程。 

         以上方法中，用的比较多是结对编程、静态代码分析、基于需求测试、基于接口测试、故障注入测试、数据流和控制流分析；形式和半形式验证这个暂未涉及；

形成测试用例的方法：需求分析、边界值分析、等价类的生成和分析、基于经验的错误猜测

除了上述描述之外，软件单元的结构覆盖度测试也有如下几种方法

 其中，MC/DC在ASIL-D认证时是常用的，MC/DC又叫修正判定条件覆盖，其定义如下：

条件表示不含有布尔操作符号的布尔表达式；
判定表示由条件和零或者很多布尔操作符号所组成的一个布尔表达式；
修正条件判定覆盖要求在一个程序中每一种输入输出至少得出现一次，在程序中的每一个条件必须产生所有可能的输出结果至少一次，并且每一个判定中的每一个条件必须能够独立影响一个判定的输出，即在其他条件不变的前提下仅改变这个条件的值，而使判定结果改变

例如，当有测试用例如下时

使用MC/DC

2.3成果物

软件验证Spec

软件验证报告

3 软件集成验证

        有了上述单元验证的经验，在做集成验证时，需要关注点除了单元验提出的之外，还需要注意其架构级别的覆盖度，如下：

         软件集成测试可以在不同测试环境下进行

--MIL(Model - in- loop)

--SIL(Software-in-loop)

--PIL(Processor-in-loop)

--HIL(Hardware-in-loop)