下载百度免费版,seo指的是什么,网站上传根目录,网站建设的关键要素1 什么是功能安全 1 背景简介 由于汽车的复杂性#xff0c;整个行业正在致力于提供符合安全要求的零部件系统。比如#xff0c;线控油门系统#xff0c;当驾驶员踩下油门踏板#xff0c;踏板上的传感器向控制器发送信号时#xff0c;控制器会综合分析如发动机转速、车辆速… 1 什么是功能安全 1 背景简介 由于汽车的复杂性整个行业正在致力于提供符合安全要求的零部件系统。比如线控油门系统当驾驶员踩下油门踏板踏板上的传感器向控制器发送信号时控制器会综合分析如发动机转速、车辆速度、踏板位置等信号然后将控制指令发送给油门本体。测试和验证线控油门系统等是汽车行业面临的一个挑战。ISO 26262的目标就是为所有汽车E/E系统提供一个统一的安全标准。 脱胎于IEC-61508的功能安全ISO-26262的国际标准草案于2009年6月发布。从草案发布开始ISO-26262已经在汽车行业获得了广泛的关注。工程师将ISO-26262视为最先进的技术状态state-of-the-art。该技术的技术状态在特定时间是开发设备或流程的最高水准。汽车制造商一般要对因产品故障而造成的损害负责。ISO-26262在汽车行业是一个通用标准它提供了一种衡量系统安全性的方法。 图1: 安全相关系统 ISO-26262使用V-Model来管理功能安全并在系统、软件和硬件级别上规范产品的开发。ISO-26262标准提供了整个产品开发过程中的法规和建议——从概念阶段到产品报废阶段。它详细说明了如何为系统和组件分配一个可接受的风险级别并对整个测试过程进行记录。一般来说ISO 26262 提供了汽车整个安全生命周期 管理开发生产运营服务退役并支持在这些生命周期阶段中定制必要的活动 提供了一种基于汽车特定风险的方法来确定风险类别ASIL; 使用ASIL来指定项目的必要安全要求以实现可接受的残余风险 提供了验证和确认措施的要求以确保达到足够和可接受的安全水平 2 评估风险——危害分析和风险评估HARA 当我们对新开发的车型有了清晰的定义后也就打响了汽车功能安全的第一枪。我们需要用HARA来识别和评估潜在的危险。一般来讲 OEM的功能安全工程师会对车辆级的功能进行HARA分析以识别潜在的危险场景并确定每个潜在危险所需的风险降低水平。HARA考虑了在特定驾驶场景中暴露于潜在危险情况的频率和持续时间Exposure纠正故障行为以减轻潜在危险所需的控制量Controllability以及在故障行为发生时潜在后果的严重程度Severity。 HARA是在车辆层面的特性上进行的而不是在零部件或者要素层面。对于每一个潜在的危险都考虑了一些潜在的驾驶方案。比如在前向碰撞缓解系统中将根据不同的驾驶场景如操作速度和驾驶条件评估非预期制动的潜在危险。 3 分配安全等级——功能安全完整性等级ASIL 在HARA过程中OEM为每个已识别的潜在风险分配了一个ASIL Automotive Safety Integrity Level等级。ASIL在开发过程中就已经确定了。根据可能存在的风险。 图2功能安全等级评定 比如如果某辆车的迈速表出了故障从车子启动开始就不显示任何信息场景可以归类为QM因为司机可以很容易地感知故障并且选择不开车或者非常谨慎的驾驶。换言之场景的可控性非常高而严重程度则很低。相比之下如果车辆无法进行控制驾驶员在高速行驶时刹车失灵的情况可以归类于ASIL-D因为这时导致人严重受伤的概率很高。 为了适当地解决这些情况ISO 26262使用ASIL评级来确定供应商必须采取的开发步骤的严格性并定义了安全目标safety goal的要求 1. FIT率Failure In Time: FIT率是车辆在给定时间段内可接受的故障率。车辆必须满足ASIL评级所规定的FIT率但OEM也可以灵活地为系统内的基础组件选择FIT率。 2. 安全概念Safety Concept安全概念决定如何检测顾故障及如何控制故障具有更高ASIL评级的系统需要更严格的故障检测和响应能力。 3. 安全要求Safety Requirements安全要求规定了对任何给定故障的适当响应。比如传感器检测到与内部安全相关的问题如内存损坏故障响应系统可能会在规定的时间内终止通过控制器的通信以便向其他系统指示其故障状态。这是安全要求所描述的典型的安全机制——但故障响应系统并不总是恰当合适的。如对于智驾功能车辆可能采用故障操作系统这要求冗余系统接管必要的时间以使车辆处于最小的风险状态比如安全停车在路边。对于系统故障遵循严格的开发过程有助于增加该功能将以一种安全的方式运行的信心。 4 持续的测试和集成 汽车功能安全在整个开发过程中都采用了V模型。V模型要求对于开发的每一步骤在测试中都必须对应有一个相应的步骤。供应商定期评估其开发过程以确保硬件和软件开发都遵循了所需要的步骤。 图3V字开发模型 OEM供应商或者独立的第三方公司对所有相关的工作产出物进行功能安全审核和评估以确保功能安全的实现。功能安全需求一个全面的管理过程以确保适当的监督和完整的系统集成。 2 什么是功能安全工程师 功能安全工程师做什么 关于什么是功能安全工程师这个问题乍一看很好回答但如果仔细思考下就会发现想找到真实统一的答案却并不容易。比如拥有完善开发体系流程的大公司和初创的小公司他们对功能安全工程师的定义大概率是不同的。思来想去还是决定以一个新项目为例来说明下什么是功能安全工程师以及在产品开发过程中功能安全工程师做什么。 1 报价阶段 1. 安全要求的分析与澄清 功能安全工程师要对客户的安全输入进行分析以确认公司内部产品的安全要求是否与客户匹配。通常会以会议的形式跟客户讨论和澄清相关安全要求。 2. 执行影响分析 分析完客户的安全要求之后一般功能安全工程师还会做影响分析以确定公司内部的平台项目或者已经量产的其他客户项目是否有可以直接复用的功能或者修改之后可以复用的功能。如果是全新的产品开发则客户忽略影响分析。 3. 开发接口协议DIA责任划分 弄清楚产品的开发边界之后功能安全工程师要跟客户去确定每一方的开发责任范围并明确开发过程中的产出物的责任方以及双方如何进行产出物的交互双方对以上内容都打成一致后DIA也就完成了。最后别忘了双方都需要在DIA上签字。 4. 准备项目功能安全计划和安全档案 在报价阶段功能安全工程师要根据项目的时间计划以及客户的安全输入来准备初版的项目功能安全计划主要内容是计划管理和指导整个项目开发过程中的安全活动的执行包含日期、关键节点、任务、可交付的成果、职责和资源等以及安全档案主要内容是与客户阐明所开发的产品已经按照ISO 26262的要求进行开发并实现了功能安全所准备的证据包含产品开发各个阶段的关键产出物的记录产出物的评审记录等。 5. 准备评审会议 以上内容都完成之后功能安全工程师就可以跟审核员Assessor约评审会议了。在会上审核员会根据功能安全工程师准备的证据对该项目的产品开发成熟度进行评估以确认是否满足当前的开发需要以及是否有安全相关的风险并输出当前阶段的评估报告。【注】由于每家公司的开发流程不同所以对功能安全评估次数要求也不同但基本都会在项目的关键节点进行功能安全评估。 6. 相关项定义以及危害分析 如果站在主机厂角度功能安全工程师要完成所开发产品的相关顶定义主要内容是在整车层面对相关项进行定义和描述包括功能及其与驾驶员、环境和其他相关项之间的依赖性和相互之间的影响并对其进行危害分析和风险评估主要是识别并分类由相关项中的功能异常表现引起的危害事件以及定制防止危害事件发声或者减轻危害程度的安全目标及其安全等级来避免不合理的风险以便得出产品的顶层功能安全目标以及功能安全概念并打包发给供应商。 2 概念设计阶段 功能安全概念/要求开发功能安全工程师要完成功能安全概念/要求FSC/FSRs的开发。功能安全概念的主要目的如下 1) 要根据功能安全目标定义产品的功能性或者降级的功能性行为 2) 要根据功能安全目标定义关于合理地、及时地检测和控制相关故障的约束条件 3) 要定义产品层面的策略或者是措施以通过产品本身、司机或者外部的措施来实现故障容错或者减小对相关故障的影响 4) 把功能安全要求分配给系统架构设计 5) 确认功能安全概念并且定义号安全确认的准则 图4功能安全目标和安全要求层级 3 开发设计阶段 系统开发设计 1. 技术安全概念/要求开发 功能安全工程师要完成或者协助系统需求工程师完成TSC/TSRs的开发。技术安全概念的主要目的如下 a. 制定系统要素和接口关于功能、相关性、约束和属性方面实施中所需的技术安全要求 b. 制定系统要素和接口实施安全机制的技术安全要求 c. 制定在生产、运行、服务和报废中系统及其要素功能安全的相关要求 d. 验证技术安全要求在系统层级是否符合功能安全要求并与功能安全要求一致 e. 制定满足安全要求且不与非安全相关要求冲突的系统架构设计和技术安全概念 f. 分析系统架构设计防止故障并为生产和服务得出必要的安全相关特殊特性 g. 按照各自的ASIL等级验证系统架构设计和技术安全概念是否适用于满足安全要求 图5系统层面的产品开发 2. 安全机制的裁剪 一般在产品设计初期开发人员已经完成了关键芯片比如Micro-controller, SBC, ASIC, Driver ICs, Intelligence Sensor等的选型。功能安全工程师在此阶段还要主导完成对芯片手册安全机制的裁剪活动哪些是产品所必须用到的哪些是可以裁剪的并给出充分的理由。 3. 系统安全架构开发 有了系统需求系统架构功能安全要求和技术安全要求后功能安全工程师就可以开始设计或者协助系统架构工程师设计系统安全架构了。设计系统安全架构要注意以下几点 a. 确保系统安全架构和前面阶段的系统架构设计的一致性 b. 系统安全架构要能实现技术安全要求相应的安全要求和安全机制最好能体现在系统安全架构中 c. 设计的系统安全架构能否被充分验证预期的软硬件设计是否能满足此系统安全架构是否方便于系统集成时测试的执行 d. 设计时要充分考虑安全相关的内部和外部接口 e. 如果此阶段需要进行ASIL等级的降级分解要按照ASIL的要求进行分解 4. 启动系统层面的安全分析 有了完整的安全要求和系统安全架构之后功能安全工程师就可以启动系统层面的安全分析FMEA分析FTA分析DFA分析了。执行安全分析的主要目的在于提供证据证明系统设计实现了相应ASIL等级的功能安全要求、识别失效原因和故障影响、识别或者确认安全相关系统组件和接口。 a. FMEA分析FMEA是一种定性的、归纳式的单点故障分析方法主要是在早期检测和消除产品设计和制造过程中的薄弱点。 b. FTA分析FTA是一种演绎式故障分析它使用布尔逻辑来分析系统不期望的状态以结合一系列较低级的事件。FTA的目标是分析在系统中发生的实际故障的路径以定位系统故障的原因。 c. DFA分析DFA的主要目的是通过分析潜在原因或者诱发因素来确认设计中已经充分实现了要求的独立性Independence独立性是指在两个或者多个元素之间没有级联故障和共因故障从而可能导致违背安全目标或相互之间免于干扰FFI免于干扰是指在两个或者多个元素之间没有可能导致违反安全要求的级联故障。如果有必要的话也可以制定相应安全措施来减轻可能的相关失效。 图不同类型的相关性失效之间的关系 硬件开发设计 1. 硬件安全要求开发 有了系统层面的安全要求、安全架构和安全分析的输入后功能安全工程师就可以开始开发或者协助硬件工程师开发硬件安全要求了。硬件安全要求主要从分配给硬件的技术安全要求和系统架构设计中导出。 图硬件层面的产品开发 2. 硬件安全架构设计 硬件安全架构设计主要是硬件架构师来负责功能安全工程师协助支持并支持做硬件架构的评审。硬件安全架构应尽量满足模块化、适当的粒度水平、简单性等特征。在硬件架构设计过程中也可以参考ISO 26262第部分中硬件架构的设计方法Table1。 图硬件架构设计原则 3. 软硬件接口列表HSI 在硬件设计阶段功能安全工程师还要协助硬件工程师完成软硬件接口列表的设计。在定义软硬件接口时要考虑好以下的要素 a. 存储器RAM,ROM等 b. 总线接口CAN, LIN等 c. 转换器 A/DD/A d. /O口 e. 看门狗内狗外狗 f. 多路转换器 【注】每家公司对HSI的责任划分也是不同的有的可能要求系统工程师或者软件工程师主导HSI的定义。 图软硬件接口概览 4. 硬件安全分析 功能安全工程师要协助硬件工程师进行硬件层面的安全分析包括FMEA和FMEDA分析。 a. FMEA分析硬件FMEA分析直接在系统FMEA分析的基础上继续对硬件组件进行分析就可以了。 b. FMEDA分析FMEDA的计算需要的输入比较多如安全目标硬件失效率目标值安全要求安全架构BOM表Mission Profile安全机制列表SN29500的基础失效率等有了这些输入就可以开始FMEDA的计算了以检查所设计的硬件产品的三个指标值SPFMLFMPMHF是否满足相应ASIL等级的要求。 图10硬件失效率度量指标值 软件开发设计 1. 软件安全要求开发 与硬件开发类似有了技术安全要求、系统需求和系统架构、硬件设计规范、软硬件接口列表和软件开发环境的输入后功能安全工程师就可以协助软件需求工程师来开发软件安全要求了。软件安全要求一般来源于分配给软件的技术安全要求或者软件功能和特性的要求如能够安全执行相关功能能够使系统达到或者维持安全状态的相关功能等。 图11软件层面的产品开发 2. 软件安全架构 软件安全架构设计主要是软件架构师来负责功能安全工程师协助支持并支持做软件架构的评审活动。软件架构的设计要尽量满足一致性、简单性、可验证性、模块化、可维护性等特征。在软件架构设计中也可以参考ISO 26262第部分中软件架构设计的方法Table2, Table3 和Table。 图12软件架构设计原则 3. 软件单元设计和实现 软件单元设计与实现主要由软件开发人员负责功能安全工程师能提供的支持相对有限。与软件架构设计类似软件单元设计也应尽量满足一致性、可维护性、可验证性等特性。在软件单元设计和实现的活动中也可以参考ISO 26262第部分中软件单元设计的方法Table5, Table6。 图13软件单元设计和实现的设计原则 4. 软件安全分析 功能安全工程师要协助软件工程师完成软件的安全分析。与硬件相比软件安全分析没有特定的方法有的公司要求做软件FMEA分析而有的公司觉得用FMEA的思路来做软件安全分析也并不是特别合适这时候通常采用一种软件关键路径分析的方法来对软件进行安全分析需要软件的动态架构和静态架构来支持分析。 4 测试验证阶段 对于各个阶段的测试话题由于很少有公司要求功能安全工程师去执行测试活动这里只简单聊一聊各个阶段的测试以及功能安全工程师在测试验证阶段要做些什么。 在各个阶段的测试开始之前功能安全工程师要主导ISO 26262方法的裁剪活动。功能安全工程师要跟系统、软硬件和相关测试工程师一起完成对ISO 26262方法的裁剪被裁剪掉的方法要给出充分合理的理由。““代表高度推荐该方法一般不能裁剪掉“”代表推荐该方法如果有合理的理由可以进行裁剪“”代表不推荐该方法 系统测试验证 系统阶段的测试一般包含以下几种 a) 系统功能测试验证系统功能是否满足系统要求 b) 系统集成测试验证组件之间的接口是否满足设计要求 c) DV测试DV是设计验证验证产品设计是否满足要求其中DV测试又包含环境耐久测试、电磁兼容测试、电气特性测试 d) PV测试PV是产品验证主要验证产线上生产出来的产品是否符合要求。一般PV之后的产品就具备了批量生产的资格了。 硬件测试验证 硬件阶段的测试一般比较关注硬件功能测试也就是基于相关硬件需求的测试以确认硬件电路设计与硬件需求是一致的。 软件测试验证 硬件阶段的测试一般包含以下几种 a) 软件功能测试验证软件实现是否与软件需求一致。 b) 软件单元测试验证单元设计是否与单元设计需求规范一致。 c) 软件集成测试验证集成的软件是否满足软件需求以及软件组件之间的接口是否一致。 上述系统、硬件和软件层面的测试验证分别由系统、硬件和软件测试工程师来负责。功能安全工程师主要关注相关的测试结果是否都通过测试覆盖度是否满足100。如果有测试失败项该测试会不会对产品的功能安全有影响。如果有失效项复测结果如何。 【注】通常故障注入测试会涵盖在功能测试里所以这里没有单独把故障注入测试拎出来。对于有些产品如果用到的ASIC有安全手册也需要对裁剪后的安全机制进行故障注入测试以确保实现的安全机制满足要求。 3 参考文献 [1] ISO 26262:2018, Part1 [2] ISO 26262:2018, Part2 [3] ISO 26262:2018, Part3 [4] ISO 26262:2018, Part4 [5] ISO 26262:2018, Part5 [6] ISO 26262:2018, Part6 [7] ISO 26262:2018, Part9 [8] SEMANTIC SCHOLAR search, A free, AI-powered research tool for scientific literature
