浅谈功能安全软件开发之追溯性

　　在功能安全开发的项目中，我们经常需要关注需求的追溯关系，因为良好的追溯可以让整个开发过程更加严谨，不会产生功能丢失或非预期增加功能。ISO26262中也在多处提到了traceability。例如在ISO26262-6（2018版）软件架构中就有如下描述：

7.4.2 During the development of the software architectural design, the following shall be considered:
a) the verifiability of the software architectural design;
NOTE This implies bi-directional traceability between the software architectural design and the
software safety requirements.

很明显，对于软件架构来说，追溯性必须要保证，甚至是双向追溯性。但是由于功能安全的开发要求已经够变态了，所以对于非必须的需求（例如NOTE），很多主机厂、供应商基本不会自找麻烦。以我本人所在的公司来说，就只考虑了是否每条SSR都分配到了相应架构模块。当然，如果使用需求管理工具，双向追溯性就可以更轻松的保证。

　　由于ISO26262更注重过程，内容和方法，所以对于实现的形式没有要求。下面给出一种追溯性实现方法：

软件架构设计追溯完整性检查表
软件安全需求编号	软件架构设计编号	检查结果	发现项	措施/建议
SSR_001	SAD_001	OK
SSR_002	SAD_001, SAD_002	OK
SSR_003	SAD_003	OK
SSR_004		NOK	SSR_004没有相应架构实现	增加相应架构

　　因为ISO-26262中要求每条需求都需要有唯一的编号，所以我们可以根据需求和架构的编号，做成上述的追溯矩阵。从表中，我们可以看出，一条需求可以由多个架构模块实现，多条需求亦可以由一个模块实现。当需求无法对应架构时，则说明追溯性不完整，这时我们需要根据实际情况考虑是否架构缺少或者需求无法实现，从而改变架构或需求。当我们列出所有的SSR编号并对应相关架构编号，需求和架构的追溯性即完整了。