|
|
大家好我是永远不会按时更新文章的克里斯。
就在几天前，同事组织开展功能安全分析活动，自顶向下分析。克里斯觉得这是个大好事，虽然这个项目FSC都没过完，however克里斯不疑有他，欣然前往。然后，炸裂的一幕发生了，组织者信誓旦旦得对克里斯说，软件也需要提供FIT值。于是我气笑了。
FIT， Failures inTime, 是一个衡量硬件元器件失效随时间分配的数值。同事之所以这样认为，时因为软件的确可以失效的无影无踪。之所以炸裂，是因为这些年，随着ISO26262的普及，很多非软件工程的同仁也熟知了软件不存在随机失效这个概念，让软件提供FIT让克里斯觉得匪夷所思。
今天克里斯就随便聊一下软件的失效和ASPICE。我们由软件工程和ISO26262出发。
软件，一种。由人基于经验和知识，在开发系统中将需求转化成自建组件并将其装载和部署的一系列活动的产物。其特点是并不存在随机失效。软件的失效一定是系统性失效，特征是其复现难度只受控于失效环境的复杂性。原则上只要失效环境可以精准重现软件失效就可以精准重现。
根据VDA德国汽车工程协会的数据，汽车行业的受控软件仍然存在1000LOC内1-10处Bug的统计结果。然而让我们丧气的是，软件失效的来源，并不全来自于Bug，可以是需求的误判。使用环境的缺失定义。架构设计时的杂乱无章。甚至可能时工具链的问题。如此一个不存在随机失效的产物，却存在如此体量的失效潜力，这的确让人非常绝望。
如果观察ISO-26262，会发现其整个ISO的核心是Absent of Risk. 而Risk从工程学上存在3个维度，软件架构作为软件的中央risk规避手段，需要同时考虑
- 项目风险：QDCR
- 技术风险：往往来自于ISO26262 / 21448 / 21434
- 过程风险: Process的实施偏差
当我们目视ISO26262-6的时候，我们会发现他的内容不像ISO26262-5给出了非常多的指标，公式，比例。6章的内容极其抽象他往往只包含
- 方法论表
- 覆盖度量表
- 环境选择表
这里引入软件有2个基本公理
1. 软件不可能没有Bug
2. 软件测试不可穷举
当我们回头看ISO26262-6，我们会明确的看到其标准在精准的平衡公理1和2即
1. 控制全部过程，而不单独以来测试结果为证据导向。扩大QA的力度
2. 在高Risk的部分进行适当的穷举，扩大QC的力度
ISO26262-6符合软件工程中认定的软件应该更重视QA而将QC作为本职工作一起纳入QA中的中心思想。
（Note: QA Quality Assurance 质量保证，即过程控制，QC：Quality Check 质量检查，即测试）
现在让我们转换视角，当你是我的客户，你心里明白软件的好坏取决于QA的好坏。这时候难题就产生了，QA不像QC可以直接调取报告进行数据处理。这时候，难道我自夸QA做的好，你就会相信嘛，显然不可能。尽管软件开发的process早在上个世纪就被敲定。但是每个公司在将软件的流程拆解的时候，仍然会存在细节上的不同。当我特立独行的时候，无疑增加了你检查我QA的难度。
有没有一种办法，像软件架构设计一样可以高度抽象每家的软件开发过程，投射去1处标准过程模型，然后提供解剖视角让各位检查呢。有的，这时候就可以拿出ASPICE。不像ISO26262提供了HOW的层级，ASPICE提供了一个高度抽象的WHAT层级模型。ASPICE不关心也不指导你如何开发软件，如何设计过程，ASPICE只回答你什么是一个过程的要素indicator。ASPICE的初衷是提供一个解剖法，将各种开发的项目分离成一个标准模型被评审。
ASPICE提供了评估模型和参考模型。然而，ASPICE也无法完全挣脱QA无法完全量化的束缚。因此ASPICE在设计的时候，将量化QA放在了达不到4级别，将这个问题公开的留给了全人类。克里斯会在空的时候回答大家对ASPICE和软件工程方法论的问题。也会将ASPICE的最新资讯和自己的思考慢慢的分享给大家。
However，克里斯永远不会准时更新。【被校长逼迫的时候会准时】
|
|
|MBD全栈技术学校|苏ICP备2025212294号-1|Hyowinner校长B站首页|手机版|小黑屋|Hyowinner的MBD技术论坛
发表于 2025-10-18 20:50:05
发表于 2025-10-18 21:03:11
楼主
