ternence

【ADI 工程师博客】功能安全的秘诀

ternence 在 2018-7-18 建立的討論區

原文链接:

https://ez.analog.com/blogs/engineerzone-spotlight/2018/07/03/if-i-could-only-keep-one-thing-from-functional-safety

 

先附上该系列博客的其他几篇内容:

【ADI 工程师博客】功能安全与人工智能

【ADI工程师博客】功能安全与安防

【ADI工程师博客】功能安全与网络

【ADI 工程师博客】IEC 62443系列网络安全标准:概述

【ADI 工程师博客】关于功能安全性,我推荐读这些书

【ADI 工程师博客】电梯的功能安全性

 

功能安全有秘诀吗?有人问过我,对于功能安全,如果有一样东西对所有产品开发工作都适用,这样东西是什么。

 

  我的回答:有力的需求管理。

 

对任何项目来说,需求管理都非常重要,但功能安全将需求管理带上了一个新的高度,而且要求尽量减少标准。

 

理论上,需求的捕捉和管理是很容易的事,只要看看相关的书,就会觉得很简单。然而,当你尝试用到实践当中时,经常会遇到各种问题。虽然,JamaDoors等工具解决了需求管理的一些麻烦问题,但仍有大量工作要做。

 

所有功能安全标准都有与各需求的属性以及需求集合相关的需求。

 

各需求需要具备诸如下列属性

  • 正确——技术上和法律上可能
  • 可行——可按预算、按时间完成
  • 清楚——无歧义,不易混淆
  • 可验证——可以确定系统是否符合需求
  • 可追溯——有独特的身份标识和跟踪方式
  • 抽象——不会对下一层提出具体的设计方案要求

 

需求集合需要具备下列属性

  • 完整性——表达完整的意思,所有需求都有
  • 一致性——需求相互之间不矛盾
  • 唯一性——每项需求仅明确一次
  • 模块化——将同属一类的需求放在一起
  • 结构化——自上而下,可追溯

 

不同需求之间存在差异,比如,航空电子标准D0-178C要求,每25行代码解决一项需求,不得有不可能执行到的代码和无用代码,但一般都有上述要求。

 

在需求属性以外,IEC 61508还有些需求坚持可追溯性,比如摘自IEC 61508-3:2010的下表。

 

A.1——软件安全需求规范

 

(见7.2

 

对于IC来说,向前可追溯性意味着,能从顶层需求追溯到实施该需求片上模块,以及用于验证需求得到满足的真实硅片上进行的测试。目的是如果值得记下一条需求,则值得确保这条需求得到了落实。反过来,如果有的设计模块不能追溯到顶层需求,则可能表示是设计师镀金或者缺失顶层需求。

 

向后可追溯性意味着,可以从在硅片上执行的测试追溯到要求进行该测试的顶层需求。向后可追溯性的优势在于,如果发现测试有问题,就可以立即知道哪些顶层需求会受到影响。如果有测试不能回溯到顶层需求,则表示缺失顶层需求,或者在进行不必要的测试。Jama等工具可以提供合规矩阵,证明存在不可追溯的需求。

 

我觉得,在术语上,多数标准的一个问题是把需求与规范这两个术语混淆了起来。需求表示要实现的要求,规范表示实现需求的一种方式。然而,许多标准将这两个术语混为一谈,甚至用到需求规范这样的术语。

 

将来可能会谈到有趣的功能安全和敏捷问题,这些地方都需要考虑需求管理。

 

如果以前用过《六人行》的视频,我表示抱歉,但这个视频太好了,我还是冒次险吧——https://www.youtube.com/watch?v=BKorP55Aqvg&t=78s

結果