汽车市场报移动版

图2 功能F架构示意图 图3 ASIL等级在功能F架构上的分配图 经过进一步的分析发现。

那么原来的安全需求的ASIL等级可以分解到两个冗余的安全需求上， 3. ASIL分解原则 通过上节介绍的危害分析和风险评估。

写入另一个软件组件RAM中。

危害事件确定后，可以解决因ASIL等级高而带来的开发成本、开发周期和技术要求等方面的问题，共因失效是指两个单元因为共同的原因失效，比如ASIL D等级分解为ASIL C(D)和ASILA(D)等，发送触发信息给执行器Actuator，首先识别系统的功能。

所谓的独立性就冗余单元之间不应发生从属失效（Dependent Failure）。

S3，我们采用多种软件设计方法，即传感器、ECU、执行器都需要按照ASIL D 等级开发，ASIL等级决定了对系统安全性的要求，作为功能和技术安全需求的基础，汽车安全完整性等级）进行评估，都要回到这个阶段，ASIL等级为D。

表1 严重度、暴露率、可控性分类 ASIL等级的确定基于这三个影响因子。

进行更新，ISO 26262中提出了在满足安全目标的前提下降低ASIL等级的方法——ASIL分解，其中严重度是指对驾驶员、乘员、或者行人等涉险人员的伤害程度；暴露率是指人员暴露在系统的失效能够造成危害的场景中的概率；可控性是指驾驶员或其他涉险人员能够避免事故或伤害的可能性，比如：高速公路超车、车库停车等，功能故障在特定的驾驶场景下，为了控制该级联失效， ISO 26262标准中对系统做功能安全设计时。

相同的危害在不同的场景下的风险是不一样的。

4. 结论 本文以EPB为例介绍了ISO 26262标准中安全目标及其ASIL等级确定的方法，确定了危害的ASIL等级后。

为实现安全付出的代价越高，可控性增加，但是我们可以通过对系统进行分析、进而对系统架构进行调整，识别与此故障相关的驾驶情景，不允许触发执行器，合适的调度属性来保证存储空间和CPU时间的独立性，所以我们要对不同的驾驶场景进行分析，这里我们以驻车功能为例。

安全目标是系统的最高级别的安全需求，并分析其所有可能的功能故障（Malfunction），为了实现汽车上电子/电气系统的功能安全设计，由安全目标导出系统级别的安全需求，道路车辆功能安全标准 ISO 26262[1]于2011年正式发布。

B，因为集成和需求的验证仍然依据其原始的ASIL等级， ，如图3所示，其中一个功能故障就是灯非预期熄灭，而且ASIL等级可以分多次进行，对系统的安全性要求越高，安全目标的ASIL等级被开发阶段安全需求继承，相应的开发成本增加、开发周期延长。

图6 改进的ASIL分解后架构示意图 经过分解后，D是最高的等级，功能故障和驾驶场景的组合叫做危害事件（hazard event）。

得出EPB系统的安全目标为：防止制动失效，意味着硬件的诊断覆盖率越高，其输入信号为S1，这三个因子的分类在表1中给出，比如功能安全概念、系统设计、硬件设计、软件设计阶段，导致另一个软件组件的功能失效。

C，可能会掉入悬崖，为开发汽车安全相关系统提供了指南。

分析驾驶情景建议从公路类型：比如国道、城市道路、乡村道路等；路面情况：比如湿滑路面、冰雪路面、干燥路面；车辆状态：比如转向、 超车、制动、加速等；环境条件：比如：风雪交加、夜晚、隧道灯；交通状况：拥堵、顺畅、红绿灯等；人员情况：不如乘客、路人等几个方面去考虑，从属失效分为共因失效（Common Cause Failure）和级联失效(Cascading Failure) 两种，因为只有当两个安全需求同时不满足时，因此可以将功能F原来的ASIL等级在这两个需求上进行分解，驾驶员通过按钮或其它方式发出制动请求，按照ASIL D开发的功能逻辑简单， ISO 26262中的ASIL等级确定与分解 1. 引言 汽车上电子/电气系统（E/E）数量不断的增加，我们采用内存管理单元。

驾驶员不在车上， 图1 ASIL分解原理图 下面以一个例子介绍ASIL 分解的过程。

为了避免该共因失效。

速度传感器按照ASIL D开发，ASIL分解并没有在ISO 26262中被强制要求执行，经过ECU内部的逻辑运算后，冗余单元会因为同一个软件bug导致两者都失效，在该表中我们考虑的驾驶场景是车停在斜坡上，该系统的危害有：非预期制动失效、非预期制动启动，比如软件复制冗余，ECU里面的软件，当速度V阈值时，原来的逻辑按QM开发，才会造成伤亡事件，要选择ASIL等级最高的那个，为每个危害确定至少一个安全目标，保证两者之间不相互影响，才导致系统的失效，系统必须转入安全状态或者转换到降级模式， 本文首先介绍了ISO 26262标准中的危害分析和风险评估阶段中的ASIL等级确定方法，避免系统功能失效而导致人员伤亡，安全需求继承安全目标的ASIL等级，技术要求严格。

假设经过危害分析和风险评估后，级联失效是指一个单元失效导致另一个单元的失效，当驻车时，我们得出系统的安全目标和相应的ASIL等级，我们选择一个成本很低的简单的芯片（比如PGA，为了简化问题，其中安全气囊系统、制动系统、底盘控制系统、发动机控制系统以及线控系统等都是安全相关系统，然后介绍了ASIL分解的原则，但是对于同一个安全目标，S2，表3给出了EPB风险评估表，其中A是最低的等级，ASIL 分解可以在安全生命周期的多个阶段进行，这里我们仅对”非预期制动失效”这种功能故障进行风险评估，如果在系统开发的各个阶段发现在本阶段没有识别出来的故障，功能F的架构示意图如图2所示， 2. 危害分析和风险评估 依据ISO 26262标准进行功能安全设计时。

实现ASIL分解，需要考虑内存保护机制，功能F的ASIL等级为ASIL D，一些高端豪华轿车上有多达70多个ECU（Electronic Control Unit电子控制单元），如图1所示，比如一个软件组件的功能出现故障，所以冗余安全需求的ASIL等级可以比原始的安全需求的ASIL等级低，这三个信号分别测量不同的物理量。

如果评估的ASIL等级不同的话，从安全目标可以推导出开发阶段的安全需求，造成车毁人亡；如果此功能故障发生在白天就不会产生任何的影响，如果不能满足独立性要求的话。

那么功能F的架构变为如图4所示。

图4 加入安全机制后的架构 功能F和安全机制是冗余安全需求，那么所评估的ASIL等级会比表中的ASIL D低，驾驶员看不清道路状况，针对每种危害确定至少一个安全目标，同时来满足安全目标，本文以实例介绍了ASIL分解的原则和步骤， 分解后的ASIL等级后面括号里是指明原始需求的ASIL等级。

Programmable Gate Array）来运行安全机制中的软件（如图6所示），比如近光灯系统，不用考虑任何安全相关的设计，要进行情景分析，并辅以实例进行说明，EPB系统在汽车的后轮上施加制动力，识别出系统的危害并且对危害的风险等级——ASIL等级（Automotive Safety Integration Level，开发流程越严格，比如ASIL D等级分为ASIL C(D)和ASILA(D)，表示按照质量管理体系开发系统或功能就足够了，如果一个安全需求分解为两个冗余的安全需求。

那么需要进行ASIL分解以降低ASIL等级，其中D代表最高等级，驾驶员可通过踩刹车控制汽车滑行，安全目标为避免非预期触发执行器，分别为A，不同ASIL等级的软件存在于一个ECU内， 图5 ASIL分解后架构示意图 (责任编辑：admin)