ISO26262功能安全--产品开发过程

 

目录

 

1.总体理解

2.概念阶段——吹牛，我们是打草稿的

2.1 相关项定义

2.2 HARA分析

2.3 功能安全目标

2.4 安全需求与安全概念

3. 系统阶段——闭门造神车，我们开始修炼

3.1 技术安全需求（TSC）

3.2 系统架构设计

3.3 安全分析与独立性分析

3.4 软硬件接口（HSI）

4. 硬件阶段——苦其心志，苦练经骨

4.1 硬件架构

4.2 硬件详细设计

4.3 安全分析——FMEDA

5. 软件阶段——打通经骨，造就灵魂

5.1 软件架构设计

5.2 软件详细设计

5.3 软件安全分析

6. 其他——遗失的美好

---

1.总体理解

功能安全可以理解为一套正向开发方法论，它强调的是正向开发，各个环节环环相扣，各个环节尽量做到可被验证，各个环节尽量做到可被管理、可被追溯，其中“V”模型开发是其中的主体思想。

 这样一套思想，一套方法，不仅仅是产品经理需要了解，凡是涉及到产品开发的任何一个工程师都应该了解，并从中汲取营养。所以我想说的是，虽然你不是功能安全经理，但是你依然可以从中获得你想要的知识。

所以在此我特意鸣谢ISO26262标准委员会，你们出的标准，我依然反反复复看且爱不释手。

下面我的语言可能有点不那么正式，希望大家小喷别虐。

        来吧，开启我们超低的PPM造车！

2.概念阶段——吹牛，我们是打草稿的

我们要搞事情，但是首先我们要确定我们来搞点啥事情，所以得弄清楚哪些事情不搞，哪些事情我们要搞大搞好搞强。

2.1 相关项定义

用我们专业术语来说，叫Item Definition，用人类更好的语言来说 叫相关项定义。下面，我们有一些具体草稿要打了。

其一，我们的“产品”要有啥功能，比如我们也是一般的车 可以前进、后退，但是还可以“横着走”，这里强调一下，应尽量站在整车角度来定义我们的功能，用我们客户的语言来善待我们的客户；

其二，我们的“产品”在哪些环境下可以使用，比如晴天、雨天、雪天、冰雹天，高温、低温、气压啥的都不在话下，但是不可以“上刀山、下火海”；

其三，我们的“产品”可能和其他“产品”发生了些关系，比如BMS离不开电池，MCU离不开电机，VCU离不开司机操作，这里的关系你可以以这种方式来描述，我离不开你哪些东西，你要我给你哪些东西；

其四，既然我们的“产品”只是“车车”的一部分，并且和其他“产品”还发生了关系，那么我们就要定义好这些关系、这些接口、这些边界条件，省的往后组装不起来，或者产品与产品之间还相互扯皮，所以为了更形象展示，画一个物理架构图，方便大家都理解，呼应下主题--吹牛我们打草稿了。

最后，我们产品都符合功能安全了，那必须得说明，咱做的产品是在全宇宙体制下，合法合规的，咱的产品可以卖到仙女座，卖到猎户座，卖到其他平行宇宙。

2.2 HARA分析

我们知道我们要搞的事情是啥子了，但是我们要把事情搞好啊，所谓要搞好，首先我们要保证用我们产品的人不要挂了，不要受伤了，要用我们“产品”的人活得好好的。所以，在产品设计前，我们提前预想好所有可能让我们上帝（客户）不安全的情况，并且定义好每种情况有多不安全，用我们专业的语言来说，首先定义危害事件，然后从S（严重度）、E（暴露概率）、C（可控性）三个角度来定义危害事件的危害等级，得出一个叫ASIL的得分表，得分越高，表示这个事件危害越高，那么我们针对这类事件就要越重视。

给大家加个鸡腿：加起来=7的就是ASILA  加起来=8的就是ASILB 加起来=9的就是ASILC 加起来=10就是ASILD

HARA分析一般主机厂来做，这个东西目前还是比较有争议的，预想后期可能会有参考出来。

2.3 功能安全目标

HARA分析之后，我们知道哪些情况对我们的“上帝”（客户）不利，因此我们就有一个方向，要着重往哪些方面加强，来提升我们产品的安全性。

这个方向是什么，因此我们就要清清楚楚的定下来，所以我们的梦想不会窒息，所以我们会稳稳的向着这个目标前进，所以我们所有努力都不会白费。那么怎样才能把我们的目标定义好呢，一般它的必备属性如下：

<

ID	描述	ASIL	FTTI	安全状态
SG1	xxxxx	D	100ms	断开xxx 关闭xxx