MUNIK解读ISO26262-功能安全生命周期
点击上方蓝字关注我们
摘要
在学习ISO 26262标准的过程中，我们会经常提到“功能安全生命周期“这个概念，对于生命周期这个词，标准的定义是“相关项从概念到报废的全部阶段“。
为了了解生命周期这个概念，我们分别从项目（产品）层面和公司层面这两个角度进行说明。
MUNIK
1
产品层面的功能安全生命周期
MUNIK
Tech
我们以图1中系统层面产品作为示例来进行说明。
图1
这张图中，我们可以看到对于产品的开发阶段，我们划分了四个阶段（第一行），分别是产品立项阶段，概念阶段，开发阶段以及工程和生产阶段。对于活动的执行部门（第一列）我们也进行了划分，部门的划分大体可以分为需求，设计，生产这三个大类，因为每个公司对于部门职责的划分都是各不相同，所以这里我们重点关注产品的四个开发阶段。
1-立项阶段：这个阶段我们的主要活动就是根据客户初期的需求或者市场调研结果判断是否立项，项目的相关管理人员也会在这个阶段明确；
2-概念阶段：立项成功后，概念阶段我们就要开始制定项目计划和安全计划，对项目所有的活动进行统一规划，对于功能安全而言，这个阶段我们有两个重要的活动进行执行，分别是影响分析（对于部分复用项目安全活动的识别）和SEooC（判断项目是否是定制开发），这两个活动都会影响到安全计划中对于安全活动的范围判定以及安全需求的制定。
就拿影响分析而言，影响分析是分析新项目在旧项目的基础上需要做哪些方面的修改，如果进行修改，会对旧项目的哪些WP（工作成果）造成什么样的影响，这些修改工作什么时候开始进行，由谁来执行等信息都会在安全计划中更新。比如旧项目是ASILB等级，而新项目是ASILD等级，因为客户对产品的随机硬件失效率提出了更高的要求，并且新旧产品在功能层面的需求相同，所以考虑在原有架构基础上新增一些安全机制尝试实现新的要求，通过影响分析活动判断下来部分IP的详细设计specification是可以直接复用;而诸如需求Spec，架构设计,FMEDA等活动需要在原有文档基础上进行修改;像FTA，高ASIL等级对应的测试验证活动等，由于旧项目ASIL较低，所以当时是没有执行，现在ASILD项目中，我们就要新增这些活动，并输出相对应的文档。
而对于SEooC而言，它就直接决定了我们的安全要求的制定，要么是客户定制提出产品需求，要么是SEooC假设获得需求，这些都会体现在安全计划的内容中。
3-开发阶段：对于图1中的示例，产品涉及硬件和软件的开发，对于硬件和软件而言，各自开发过程基本相同，从获得HSR/SSR（硬件安全需求/软件安全需求）→架构设计→详细设计→集成设计，以及每个环节的验证活动，包括我们重点关注的FMEA,FTA,DFA,FMEDA这些安全分析活动也都是在这个阶段来执行的。此阶段的活动就是为了在技术层面将产品需求实现。
4-工程和生产阶段：当上阶段的开发工作结束后，我们就要将设计转化为实体的商品，此时我们便要联系生产和封装厂进行生产活动，这里就要包括对生产工艺的要求，生产的计划安排以及生产过程的其他管理活动。生产结束后客户在使用过程中遇到的一些调试，安装等问题要求，产品出现质量问题的售后服务以及产品在达到使用寿命后所要采取的必要保费措施，都会记录在这个阶段。以上内容就是一个系统层面产品生命周期中会出现的活动。
2
组织层面的安全生命周期
MUNIK
Tech
公司层面的安全生命周期相较于产品层面就没有那么复杂，对于公司而言生命周期其实就是公司可能会涉及的标准范围，也就是标准part2-5.4.6（独立于项目的安全生命周期裁剪）的要求。下图2是ISO 26262经常会看到的一副标准章节图。
这里面将标准所有的章节及对应的安全活动进行了展现， 可以简单地理解上图就是功能安全在公司层面最完整的生命周期，不同的公司的安全生命周期只会比此范围小，不会超越此图的范围，不同公司将此图中不涉及的章节或者安全活动裁剪以后的结果就是该公司组织层面的生命周期，已下表中的内容为例给大家进行说明。
表格前两列列举了标准从part2-part9的主要内容（这里暂时只考虑与实际项目实施强相关的几个部分），后4列我们是划分了四种类型的公司，标记了它们对应ISO 26262标准生命周期常见的几种情况。
1-对于OEM厂商而言，它们属于汽车E/E开发需求的发起者，而且是产业链的最终集成者，所以OEM是会涉及标准的所有章节，因此他们的生命周期就是完整的ISO 26262范围。
2-对于系统集成商而言，他们的产品一般会先集成到Tire1&Tire2的产品中，然会才会应用到整车上进行使用，他们一般不会直接承担整车的某项功能，所以标准part3的活动对于他们而言是不涉及的，因此在他们的生命周期中是要裁剪掉的，而对于系统的设计工作（part4），软件硬件的设计工作(part5&6)，支持部分（part8中的安全需求管理，DIA,配置管理，变更管理等），安全分析（part9）这些都有可能会涉及，因此在他们生命周期中这些都是要保留下来的。另外对于部分系统开发公司，可能会存在没有产品的实际生产能力，所以part7对于系统层面有被裁剪掉的可能性。
3-对于一个纯硬件公司，首先part2,part8的管理和支持内容肯定是要保留，并且因为它们是专业的硬件设计公司，所以part5的设计内容以及part9的安全分析内容也是要保留，因为是纯硬件公司，所以软件部分的part6则需要裁剪掉，part3因为是相关项层面的活动，所以也不会涉及。而硬件公司，可能会去开发通用组件而假设客户的需求，所谓的客户其实就是系统层面的集成商，因此就可能会通过SEooC假设到系统层面的需求，也就相当于part4-6的内容，因此硬件公司关于part4是可能会设计到的。Part7就和系统层面的理由一致，可能会涉及到，也可能会被裁剪掉。
4-对于芯片生产，封装厂，因为不涉及功能安全的设计环节，所以part3—part6都不涉及，会被裁剪掉，与其相关的就是part2的管理部分，part7的生产部份，part8的支持部分。
以上内容就是生命周期在产品层面和组织层面的内容。
——原创文章，转载请授权并注明出处，否则必究。
