功能安全学习-Case study: 扭矩安全概念设计(中)
我们接着上篇继续，在确定危害事件和对应的ASIL等级以后，需要基于危害事件确定Safety goal。
5. 制定功能安全目标(Safety goal)
一个功能安全目标可以对应若干个危害事件，需要取其中最高的ASIL等级作为该安全目标的ASIL等级。另外，每个安全目标必须定义一个安全状态(Safety state)。安全状态可以是单独的安全模式，也可以是逐步降级的过程。我们还是按照上次的扭矩安全的例子，继续学习安全目标(Safety goal)如何确定下来？
安全目标要写到什么程度呢？这个问题，我跟几个做功能安全的同事讨论过，是不是在Hazard描述里加上Avoid就行了呢？我个人的理解是要看你具体的分析对象，如果分析的是诸如Hybrid system这类大系统，写Safety goal时，可以按照上面的例子来写。但是如果分析的是子系统，Safety goal时，仍然写到整车层面的安全目标就不是特别合适了。我并不认为这是抠字眼的过程，开发人员能够理解你的安全目标，这是我们做功能安全的目的。ISO2626(第三章,6.4.4)里面关于Safety goal的描述非常到位，要写到相关项的Top level requirements。
我们再举一个例子，高压混合动力系统中的DC/DC部件。如果DCDC低压侧发生过压，车上的12V Ibooster有可能会产生失效，产生的危害是非期望的车辆减速度丢失(由于Ibooster失效导致的)。
如果我们写的安全目标是避免非期望的车辆减速度丢失，DCDC开发工程师很难去理解DCDC 12V侧过压跟车辆减速度丢失有什么关系，很难去理解Ibooter是个什么东西。在他们的知识体系里是C语言, MOSFET, PWM控制这些东东。所以在DCDC这个子系统的功能安全开发中，我们的Safety goal应该写成：
这里面涉及到一个Level分层问题，说白了就是各司其职，各自管好自己的圈和地儿。在Hybrid system HCU层面的关键词是扭矩和转速的控制，ABS层面是纵向减速度控制，DCDC层面是高低压侧电压电流这些控制量。
需要补充一点的是，12V电压过压时，iBooster不一定会完全失效，会由电助力建压慢慢切换到机械建压，提供必要的机械制动力。切换过程中，有可能会产生减速度不足的情况，但是不一定会导致减速度丢失。6. 确定功能安全需求(Functional safety requirements)
在安全目标(Safety goal)和安全状态确定以后，必须在其基础上进一步对故障检测，容错机制提出细化的技术要求，形成功能安全需求(FSR)。结合系统的初步架构设计，形成功能安全概念(Functional safety concept)。
ISO26262中提到了，完整有效的功能安全概念应当包括：
（ISO2626-第三章7.1）
所以开发的结构顺序变成了如下图所示，一个Safety goal不止一个功能安全需求，同样地一条FSR也可以对应多个Safety goal。
下图给出了功能安全要求的结构和分布的说明，将功能安全要求分配给初步架构要素。
接着扭矩安全的Case,我们整理下功能安全需求，如下图所示。如果分析的对象是上层控制器，FSR中的描述针对的都是HCU如何实现。这里还没有涉及到FSR的分配，这一部分又有不小的工作量。
如果我们的分析对象是针对电机控制器，分析过程如下表所示。我这里写的FSR不一定合适，颗粒度把握和描述是需要仔细斟酌的，但是电机系统(Motor+Inverter)里，FSR都应该是针对这个子系统的，比如电机转速传感器、直流母侧电流，这些信号和电机扭矩是直接相关的。
但是这里仍然有个问题，你的FSR怎么算是写的全了呢？怎么就是表述和范围清晰的呢？在这里，就要用到2个方法：FMEA和FTA
FSR完成以后，下一步就进入到ISO26262第四章的部分：产品系统层面开发。在这个Case study的最后一期，我们要基于FSR和FSC做技术安全需求和功能安全的系统设计。
这2期花了很多时间来整理功能安全的思路和流程，写了很多废话关于FSR,SG这些概念之间的关系。Anyway功能安全活动的流程和思路理清楚了，后面就是Case by Case分析以及不断积累的过程了。
持续改进，不断学习，咱们下期继续。
- 用户评论
