ASPICE与ISO26262

近日常被问及ASPICE与ISO26262的关系，特将1年前在某次大会上的演讲整理成文章，以解疑惑（本文内容非常基础，资深人士可绕行）

话题1：什么是汽车功能安全(Automotive Functional Safety)

任何一个提供功能的产品，其功能都可能会发生'故障功能Mal-Function'。比如：商场里面的电梯可能会产生'突然加速'、'反方向运动'等'故障功能'。'故障功能'可能会对人的生命或健康产生影响(Harm)，当这种Harm所产生的风险是不可接受的，就需要采取一定的'安全措施(safety measure)'将风险降低到可接受水平。

通过采取'安全措施(safety measure)'，将功能相关的风险控制在可接受范围内。就可以说功能(Function)是安全(safe)的，这就是功能安全(Functioanl Safety)。

汽车功能安全(Automotive Functional Safety)是指汽车的E/E系统所相关的功能的安全。

如何分析'故障功能'相关的风险的'可接受程度“呢？

在汽车功能安全领域，是通过三个方面来判断的：

• 故障功能所产生的Harm的严重程度(Severity)；

• 可能发生'故障功能'的场景的可能性(Probability of Exposure, 场景曝光度)；

• 发生故障功能后，受影响的人能避免伤害的程度(Controliability，可控制性)
  

基于如上三个方面的分析，得到故障功能的风险程度（ASIL，汽车安全完整性等级），按照风险由高到低，分别是：ASIL D, ASIL C, ASIL B, ASIL A。风险程度也可以是QM(Quality Management)。当风险程度是QM时，说明其风险是可接受的，按照质量管理体系的要求进行管控即可。

有哪些安全措施(safety measure)呢？

• 安全机制(safety mechanism)：是指产品中的一些技术措施，比如软件中采用的输入/输出数据的范围检查、控制流监控等。这类技术措施是在软件设计开发过程中设计的，在产品被使用时被应用的，可称之为for product operation。
  

• 安全措施(safety measure)：除了包括上述的安全机制(safety meachanism)外，还包括一些活动的措施，通过采取这些措施，从而避免或控制产品失效。如下两幅图所示的，就是这类活动的措施，下图一是软件工程过程、下图二是软件代码的编码规约。

安全措施(safety measure)包括两类：

• 一类是安全机制(safety mechanism)；

• 一类是与活动或过程相关的措施。
  

在讲到安全措施时，也需要提及一类特殊的安全措施，叫做认可措施(Confirmation Measure)，认可措施(Confirmation Measure)的详细解释，可参照本公众号的另外一篇文章：ISO26262中的认可措施与Automotive SPICE评估之间的关系

汽车功能安全的ISO标准是ISO26262，目前最新版本是2018版。

2011版本包括如上两图所示的10个部分。

说明：本文的演讲资料是2018年所做，是以2011版本为基础的，从理解26262的概念和思路上来说，是完全可以的。2011至2018版本的变更，也可阅读本公众号的文章：ISO26262第2版新看点

Part 3 ~ Part 7覆盖产品的整个生命周期：

• Part 3: 产品概念阶段，包括在整车层面进行危害分析和推导出安全目标，并将其分配给不同的部件。本阶段活动往往由OEM来实施。
  

• Part 4: 产品系统开发阶段，包括为某个部品设计技术安全需求(安全机制)、系统设计以及软硬件开发完成后的集成及相关测试。本阶段活动往往由Tier 1来做

• Part 5/6分别是软硬件的设计和实现
  

• Part 7是产品的SOP之后的生产、运营、维护及报废等

• Part 2 是功能安全管理，包括组织层面的功能安全管理和项目层面的功能安全管理

• Part 8 是支持类过程，其中功能安全特有的过程包括软件组件的资质认定、硬件组件的资质认定、软件工具的置信度等
  

• Part 9 定义了相关的功能安全方法，如：ASIL分解、安全分析等

ASPICE是什么，在此处不再进行解读，读者可参照本公众号相关文章对其进行了解。

接下来我们讨论下一个话题：

话题2：ISO26262与ASPICE之间的关系

上图来自于Automotive SPICE模型，过程可以分为三个层次，

• 第1个层次是'What(什么)'；

• 第2个层面是'How(如何做)'，是为了满足What的要求，需要如何来做；

• 第3个层面是'Doing(做)'，是按照第2个层面所定义的方法来“做”以满足第1个层次的What要求。
  

Automotive SPICE PAM的要求都是在第1个层面，都是“What(什么)”层面的要求。比如：ASPICE要求定义项目范围(但没有提示如何定义项目范围)；ASPICE要求进行软件架构的动态设计(但没有提示如何动态设计)。

ISO26262里面的要求既包括第1个层面的What要求(如前文图片中的软件工程过程)，也包括第2个层面的How的要求(如前文图片中的代码规则)。

ISO26262与ASPICE进行对比：

• ISO26262是功能安全产品标准；ASPICE是过程模型

• ISO26262适用于小于3.5吨的量产乘用车中的汽车E/E系统(注：2018版的ISO26262的适用范围有所增加)；ASPICE适用于车载的包含嵌入式软件的系统

• ISO26262是覆盖整个产品生命周期；ASPICE是覆盖项目生命周期(包含嵌入式软件的系统开发项目)

• ISO26262的要求有What层面的，也有一定程度的How；ASPICE的要求都是What层面的

ISO26262中所要求的功能安全要求，需要企业在其现有的质量管理体系之上进行建立；企业的质量管理体系首先是基于IATF16949，之后可以应用ASPICE对其进行完善和细化。

ASPICE模型帮助企业建立：组织过程以及基于PDCA的持续改进机制。有了ASPICE对企业质量管理体系的支持，企业的质量管理体系的有效性和适用性会更强。

ASPICE和ISO26262同时都覆盖了系统层面的开发、软件层面的开发、项目管理及一些支持类过程。对某一个过程来说，如果有ASPICE要求，又有ISO26262要求，可以将要求进行合并。

• 活动的要求：ASPICE中BP/GP + ISO26262中的Requirements and Recommendations

• 工作产品的要求：ASPICE中的Output Work Producct + ISO26262中的Work Product
  

如上两图是以'软件详细设计和编码'为例，展示如何同时考虑ASPICE要求和ISO26262要求。

企业其研发过程可能需要考虑各种各样的模型或标准。不同的模型或标准是从不同的维度提出的要求，企业在应用时最好不要为每个模型或标准都单独建立一套企业内部的要求。而是需要从企业内部实际出发，来融合不同的标准或模型。

如上三个图是将ASPICE与ISO26262中的过程进行的Mapping，供读者借鉴。