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描述ASILFTTI安全状态
SG1xxxxxD100ms

断开xxx

关闭xxx

     

夹个鸡腿给大家,前面我们提到了“V”模型贯穿开发过程,这里的【安全目标 】是由后面的 【安全确认】 这个子活动来验证。

2.4 安全需求与安全概念

我们有个伟大的目标,但是目标之所以伟大,而不是空想,是因为我们将其分解为一步一步,直到我们可以真正实现。所以这个目标必须细化为可实现的步骤。

所谓的功能安全概念,就是从安全目标中导出功能安全需求,并且将安全需求分配到系统初始架构的各个单元中去。

所以这里我们有两件事要做,一是安全需求,二是初始安全架构。

有了安全目标和相关项定义,我们可以导出安全需求;

有了安全需求和相关项定义,我们可以初步设计安全架构;

下一步,应把安全需求分配到初步的架构元素中去。

这样一说,似乎有点点空洞啊,我可不能只会吹Bi,所以我打算举起一个栗子(比心):

咱们的车车都有车门吧,对于车门来说,它具有开门和关门功能(基本功能定义),当车速过高的时候,我们认为不太安全,所以车速大于xxKM/H时,应避免车门打开(安全目标),我们的车门一般有个ECU来控制它,一个ECU一般由传感器 处理器 执行器组成(初始架构),因为和整车车速有关,因此我们这个ECU的传感器就应获得车速,这个车速信息是其他的ECU通过CAN线传过来的,那么我们就可以这样写两条功能安全需求:

FSR1:那个叫“其他”的ECU应将正确的车速信息发送给“我们的”ECU;(这条不好,可忽略)

FSR2:“我们的”ECU的CAN链路应正确获取车速信息。(CAN链路这个架构元素就被分配了一条安全需求)

又来给大家夹鸡腿了,这里的功能安全需求的验证活动 对应 Item的集成与测试。

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

前面,我们已经把产品的“草稿”打好了,好啦,我们要正式开始修炼了。

3.1 技术安全需求(TSR)

前面我们做过一部分分解工作,比如将安全目标,分解到安全需求和初步架构,要实现那个“伟大的”目标,我们要更加脚踏实地,因此要进一步的细化我们的工作。所谓的技术安全需求,就是要结合实际(不能吹牛了),提炼成一条一条可以实现的需求。为了不至于太飘太空洞,我们延续上面的FSR2来讲一讲TSR应该如何写:

TSR1:“我们的”ECU通过CAN链路获取的车速信号应通过E2E保护确保信号的正确。

发现木有:所谓的TSR就是把具体的方案以及安全机制加入进去了。

3.2 系统架构设计

我们都有TSR了,说明在我们心中,我们有安全机制,也有安全方案了,所谓系统架构设计,就是将我们的需求,方案,安全机制以及功能模块,用框图的方式描述出来。一提到架构,我们第一时间要反映过来的就是接口,对这个框图就是要重点展示各个模块的输入接口,输出接口,同时将我们的接口串起来,就是系统架构了。

虽然鸡腿吃多了长胸,但是这里还得夹两个鸡腿,因为功能安全要求环环相扣,因此这里的TSR的ID要与系统架构的ID对应,确保需求与架构对应,此外模块的接口参数应在架构的接口参数中体现,确保模块与架构对应。

3.3 安全分析与独立性分析

前面我们提到了HARA分析,那是从整车角度分析各种危害,下面我们要根据我们已有的安全目标,来分析我们的产品有哪些情况会危害到安全目标。HARA针对整车,这里的安全分析就是针对我们的系统。

一般有两种方法,一种叫FTA,一种叫FMEA,前者是演绎分析法,是一种从上往下找出违背安全目标的原因,后者是归纳分析,是一种自下往上的分析方法。在功能安全开发过程中,一般利用两者来分析验证架构是否满足安全需求。

独立性分析,其实应该是相关性失效分析,就是大名鼎鼎的 DFA,主要是识别不同的ASIL等级的模块之间是不是有共因,是不是有干扰,比如A失效,将到时B和C同时失效,那么A就是他们的共因,而DFA就是为了识别系统中所有这种共因。

3.4 软硬件接口(HSI)

一个系统是由软件和硬件组成的,一个功能也是需要软硬件的配合才能实现,一般情况下,软件开发和硬件开发不是一拨人,虽然我们是一个Team,但是我们专长不一样,为了让我们这个Team更好的协作,因此我们定义了一个叫HSI的东西,它其实就是软硬件沟通的桥梁。同时硬件别来扯我软件的皮,软件也别扯我们硬件的皮,大家皮肉各自在一起。

HSI咋写呢?小编 我又来举起“栗子”(比心):

比如我们要获得 某个温度,硬件要干的事情就是 用一个传感器,给其供电,获得一个电压值,通过芯片的ADC采样,转换为一个数字值(0~4096),软件根据这个数字,通过一定的系数(或查表)转换为温度,同时为了提高这个温度值得可信度,还需要做一些诊断监控,比如传感器掉线了,过温等。因此我们要提炼下上面的属性,把这样一个软硬件交互清晰定义下来。

归纳HSI的要点属性就是:硬件PIN脚、对应芯片的引脚、是输入还是输出、模拟量还是数字量、规格参数(系数、偏移、表格标定等)、安全等级要求、详细的需求以及采取的安全机制等。各位看官可以动动手,按照这个属性,把上面的 栗子 写一下。

再次给各位客官奉上 一记 香喷喷的鸡腿:这里的HSI 通过后面的软硬件集成与测试活动来进行验证。

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

系统阶段给我们搭了一个框架,硬件阶段,我们来好好捯饬捯饬这副经骨。

4.1 硬件架构

系统把一部分TSR(技术安全需求)分给硬件来实现,那么我们进一步细化就得到硬件安全需求。硬件安全需求就是将需求落实到具体的硬件功能甚至元器件上。提到架构我们第一时间要想到啥? Yiiiiiiii,莫不是接口吧。所谓的硬件架构,就是将硬件的功能分解为一个一个子功能,然后定义好每个子功能的输入和输出接口,最后串起来就是硬件架构。所以这里最核心的工作就是如何很好的分解一个一个子功能,这,我当然不好给大家举栗子了,希望大家在设计的过程中,把架构设计的秘诀——解耦内聚 牢记于心吧。

继续夹鸡腿:这里的硬件架构的验证  会在后续的硬件集成与测试来进行验证哦!

4.2 硬件详细设计

这里的详细设计就是,将上面一个一个分解的功能,进行原理图级别的设计,更通俗点就是把各个元器件,按照要求给串起来。最近不是老美在打压中国嘛,这种原理图设计工具不知道受不受影响啊,这是题外话。

到了这一步的话,就要SCH、BOM、PCB了,相信搞硬件的贼**熟悉。

哟哟哟,鸡腿飞来了、飞来了、飞来了,这里的详细设计将会对应硬件的单元测试哦。

4.3 安全分析——FMEDA

前面进行了一部分的安全分析,比如系统FMEA、FTA,但是这些分析仅仅是定性分析而已,作为处女座追求完美的我们,造出来的产品,那必须也是可定量评估其好赖的。因为为了准确评估出硬件随机失效,在硬件详细设计后(过程中),就要进行FMEDA。搞几个专业词汇来吓唬吓唬你们,比如ASILC的产品,要求PMHF < 100FIT,SPFM≥97%,LFM≥80%(不懂得小伙伴去查查标准哦,用来测测你爱不爱ISO26262 ...其实是我懒,不解释)。对,没错,FMEDA就是去校验这几个参数,是否满足我们开始预期的ASIL等级要求。

一般要玩这个玩意(FMEDA)还是借助下工具吧,过程的话,就是将你的硬件BOM导入工具,然后一个一个元器件去分析,当然不能凭空分析,一般工具需要你买两个行业标准库,叫SN29500以及IEC62380来获得基础失效率,然后通过计算获得一个汇总的失效。具体计算过程,其实ISO26262 标准的附录里面给了例子,小伙伴有兴趣还是好好去看看那个例子吧(小编我又很懒,不解释)。

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

这个名字有点霸气啦,其实主要是为了体现在汽车电子领域,软件工程逐渐变得越来越重要,甚至后续会变得更加重要。所以我称之为咱“产品”的灵魂(发个小广告,别撕我的小卡片,我的其他博客,有对软件更多详细介绍哦)。

5.1 软件架构设计

系统设计完之后,有些TSR就分配给软件了,进一步细化就得到软件安全需求,如何细化?就是把TSR细分到具体的软件元素上去。

架构设计,就是根据分配给软件的需求,分解功能,定义好各个功能的交互接口。软件架构设计,可是大有来头啊,我依然无法一句话两句话说清楚,汽车电子领域其实有一个架构很不错,叫Autosar,这可是一波顶尖的人才搞出来的,值得学习。还是那句秘诀——解耦内聚。哦,别忘了,除了静态架构,记得动态的架构也要哦。

再补两句话,我认为一个好的架构就是,各个模块之间的交互关系很清晰,你知道数据流怎么走,控制流怎么走,你可以一眼看出他们的层次、逻辑、时序关系,你底下的实现兄弟,只要负责实现,系统拼起来就可以正常工作。

飞来了,飞来了,你的鸡腿请接住,这里的架构设计的验证 对应 软件集成与测试 这个子活动。

5.2 软件详细设计

同样的,软件详细设计就是实打实的码代码,或者建模了,其实在汽车电子领域,大家都会认为建模比写代码好,因为建模更简单直观,同时基于MBD开发,测试结果很好统计,同时因为汽车更注重的是安全,而不仅仅是代码的执行效率,我想MBD会是主流吧。

鸡腿,Bling,Bling,这里的软件单元的验证就是对应 软件单元测试了。

5.3 软件安全分析

虽然软件无法像硬件那样,具体计算一个失效值出来,但是必要的安全分析也不能少,一般我们称之为SWFMEA,即软件FMEA,其实就是把安全相关的组件(软件功能单元)的接口,函数,参数等分析其失效模式,然后按照ISO26262的安全机制的诊断覆盖度参考,确认当前设计的组件是否满足诊断覆盖度要求,若不够则增加安全机制或者预防措施等。

6. 其他——遗失的美好

其实,还想强调总结一下以上各个活动的追溯关系,就是每章节后面给大家夹的鸡腿,我想鸡腿够多了,有兴趣大家自己去理一理把。

此外,还有些支持过程,生产制造过程,以及安全管理等等这些内容,都是我遗失给大家的美好(无奈,小编也没有直接经历),我希望大家不要留有遗憾,都去看看标准,别让这些美好,变成自己的遗憾。

当然,如果对小编有兴趣,或者想沟通交流。

 

 

 

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页