功能安全产品开发中的一二三四：一个理论两个维度三个方面四个要素...

来源：公众号“汽车功能安全”

2021-05-13

2786

初看功能安全标准时最大的困惑往往是：“ 我们该如何将功能安全真正与公司的实践相结合并开发出符合功能安全标准的产品？”

多刚刚接触功能安全的人常常会进入一个误区，认为“功能安全就是一个文件体系，只要按照标准把文件准备好就可以了，比如，对于软件单元，功能安全提出了明确的要求，好像只要我们管好版本、符合MISRA C并且进行了必要的测试而且覆盖度达到了要求的指标比如MC/DC 100%我们就符合功能安全了”，然而，事实并非如此。

序

本文将为大家介绍功能安全开发过程中会涉及的几个重要方面，笔者将其概括一个理论两个维度三个方面四个要素，希望通过本文，大家可以对功能安全相关产品开发有更多的了解。

功能安全标准属于比较典型的指南型标准（就是那种具体到你该如何做的标准，更多内容可参见汽车电子读书笔记-安全标准与认证04-标准类型）制定标准过程中，无论是技术还是流程大家关注的都是当前技术水平下的最佳实践。虽然，有了最佳实践但是如何将标准中规定的最佳实践与现实开发结合在一起，标准觉得这是企业自己的事与标准无关，而这部分内容又恰恰是很多初学者最容易困惑迷茫的地方，就像是课堂上老师讲了方法但是并没带着大家一起练习一样，结果是每次看标准都觉得自己懂了，但是一到现实就是不知道该怎么做。

这种困惑在很多初学者尤其是没有做过完整项目的初学者身上表现的最为明显，因为缺乏基础的项目开发经验以及必要的专业知识，往往都是只知其然不知其所以然的状态。

四个要素

先有产品才能谈安全，在我们真正应用功能安全之前，我们需要首先认识清楚开发一款产品的4个基本要素PPRT即P（Process流程）P（Person人）R（Requirement需求）T（Tool工具）。

Process流程

首先是P（Process流程），任何组织开发产品都会有过程，差别最直观的体现就是对过程定义的完整程度和文档化程度，比如有的组织即便是没有任何文件，但是负责项目或者开发的人很清楚产品开发的套路，依然可以组织人将产品开发出来。当然，更多的组织是靠明确的流程来定义开发活动的组织步骤。而流程定义的明确与否，最直观的反馈就是产品的质量。理想的开发过程中，每一项活动的完成都需要明确的确认（此处的确认包含各种评审以及验证机制），不然，我们没有办法保证，我们的产品是否真的是按照要求在进行开发，或者说产品中是否存在由于疏忽等意外因素导致的“坑”。我们的客户更不敢相信我们的报告，因为没办法保证它是否真的来自于最终发布的产品，再者由于认知偏见的存在(来点心理学 | 什么是确认偏见，我们该怎么克服)，我们更加需要评审或者监管来克服自身问题。比如phlip koopman认为在软件单元评审阶段，尤其是同行互审可以检查出50%以上的软件bug。

Person人

P（Person人）开发活动的核心是人，而且每个人的经验与知识储备都存在差异。每一项开发活动都需要有明确的人员资质说明，人员的专业水平不仅关系开发的周期及成本更关系到产品的质量。虽然，测试工具可以帮助我们减少很多潜在bug，但是，由于工具的局限性（比如同样的矩阵处理，不同的编码方式可能会产生数倍的运行时间差别），还需要丰富的经验来保证工作的效果，这种情况下必要的资质鉴定和能力提升就显得十分重要。

Requirement需求

R（Requirement需求）需求是产品或者活动存在的意义，也是将各项过程联系在一起的纽带，组织中每一项活动的进行都是因为有对应需求，这种需求包含安全方面的需求、功能方面的需求，法规方面的需求，质量方面的需求以及性能方面的需求等等。

Tool工具）

T（Tool工具）工具作为开发活动中必不可少的一部分，对工具的了解程度不仅影响开发活动的进度还可能直接影响产品的安全。购买的开发工具，无论是否经过认证，都需要工具供应商提供这款工具的勘误表Errata,它是后续开发工具认证以及使用指南制定的重要参考。高效的工具需要正确的运用，才能发挥出它的价值。

有了上面四个开发过程的基本要素，我们再来看产品的开发过程，可以理解为合适的人遵循明确的过程，正确的使用开发测试工具开发满足合理需求的产品。有了这四个基本要素，我们可以进行产品开发了，但是，对于需要满足功能安全标准的产品，还需要有更多的考量。

三个方面

三个方面即：H（危害 hazard ） R(风险risk) M(安全措施Matigation)

首先是与安全紧密相关的三个方面即H（危害 hazard ）R(风险risk)M(安全措施Matigation)这三个术语的定义可以参考文章汽车电子读书笔记-专业术语解析01，功能安全标准虽然给出了安全的度量指标ASIL以及相关的方法论HARA，但是，对于如何分析并没有给出具体的方法论，这里我们可以参考文章危害与风险分析方法论 | HACCP 和 HAZOP提供的方法帮助我们进行分析。这三个方面不仅仅是开发的起点，也是我们组织安全档案并向客户证明产品安全性的重要说明点。当然，这三个方面（即危害识别、风险分析以及安全措施设计）知识的运用过程，已经超出了功能安全的要求，主要考验开发者及其所在组织对其产品认知的深度。

两个维度

有了上面的三个方面与四个要素作为基础，我们才算是正式进入了功能安全产品开发的大门，这时需要参考标准对开发的过程及产品进行两个维度的评价，即最佳实践BP与当前技术水平SOA。

功能安全标准中定义的最佳实践（Best Practice BP)更多强调的是过程模型这个维度内容，即我们在产品开发过程中应该干什么的问题。而在过程能力这个维度即我们做的怎么样？这个维度并没有明确的量化指标，这部分内容需要在ASPICE或者CMMI中进行补充。在我们充分理解上面开发产品的四要素和三个方面的前提下，我们可以首先进行流程的文档话，在文档话的基础上，我们可以结合功能安全标准提供的最佳实践内容比如V型开发模式，down to unit的软件开发方法等进行一定的修订，指定符合功能安全标准的最佳实践流程。

在我们探索并制定属于本组织的最佳实践流程时，需要考虑当前技术水平（State Of Art),比如，从C语言编码的角度，我们需要最新的MISRA C2012，它可以帮助我们定义更加安全的语言子集。再比如，我们可以利用动态测试工具中，新增的CTE分析方法来减少测试用例的冗余度等。当前技术水平SOA不仅可以帮助我们提高效率改善产品安全性，还是未来不幸遇到安全纠纷时，有力的证据。

在将上述过程都运用好之后，我们依然不能放松警惕，功能安全标准的终极目标是帮助我们开发更加安全的产品，我们应用标准的目标也是使我们的产品更加安全。我们切勿在追求产品认证的过程中忘了自己的初心。我们需要时刻提醒自己，功能安全是基于一个理论的，即可靠性理论。它认为研究安全即是研究失效，这个理论很好，但是，在目前日益复杂的系统结构尤其是机器学习算法的应用及网络安全问题的凸现情况下，这个理论已经不够用。需要我们在开发过程和技术应用方面持续进行优化与改进。

上一篇：提高自动驾驶安全性的关键是什么？下一篇：城轨云的前世今生（上）

用户评论
共0条评论

2000

同类文章推荐

功能安全产品开发中的一二三四：一个理论两个维度三个方面四个要素...

合作伙伴