电子电气系统开发流程中的功能安全

上传人:枫** 文档编号:500683110 上传时间:2023-10-16 格式:DOC 页数:4 大小:122.50KB
返回 下载 相关 举报
电子电气系统开发流程中的功能安全_第1页
第1页 / 共4页
电子电气系统开发流程中的功能安全_第2页
第2页 / 共4页
电子电气系统开发流程中的功能安全_第3页
第3页 / 共4页
电子电气系统开发流程中的功能安全_第4页
第4页 / 共4页
亲,该文档总共4页,全部预览完了,如果喜欢就下载吧!
资源描述

《电子电气系统开发流程中的功能安全》由会员分享,可在线阅读,更多相关《电子电气系统开发流程中的功能安全(4页珍藏版)》请在金锄头文库上搜索。

1、E/E 系统开发流程中的功能安全 一、 概述 随着汽车成为我们日常生活不可或缺的重要交通工具,消费者对汽车的安全性、 智能性和娱乐性要求日益提高,政府在制定汽车技术法规时考虑越来越全面(例如美 国、日本、欧洲将 TPMS,Tire Pressure Monitoring System,胎压检测系统列为强制 要求)、法规的要求也越来越严格(例如预计到 2017 年 1 月 1 日,全国新制造、销售 等级的轻、重型汽油车必须符合国五标准),使得汽车上的 E/E(Electronic and Electrical,电子电气)系统越来越复杂。具体到汽车安全性要求,国际标准化组织(ISO) 制定的 IS

2、O26262(Functional Safety,功能安全)成为近年来行业内讨论的热点,但是在车型 E/E 系统开发流程中应如何考虑功能安全,许多工程师还存在疑惑。 我们多年来通过大量项目积累了较为丰富的 E/E 系统开发和功能安全咨询经验, 对 E/E 系统和功能安全都有比较深刻的认识。因此,本文将为大家剖析 E/E 系统开发 流程中的功能安全。第二章会先介绍没有功能安全的 E/E 系统开发流程,接下来第三 章介绍功能安全过程,最后第四章介绍引入功能安全后的 E/E 系统开发流程。二、 E/E 系统开发流程 E/E 系统开发流程涉及整车 V 模式开发流程中的前三个阶段:需求定义、架构设 计和

3、系统设计。需求定义阶段的主要工作是“用文字描绘出要做什么样的车”,即根据市场调研结 果(用户需求、对标车型、法律法规等)和历史车型数据整理出整车配置表、VTS(Vehicle Technical Specification,整车技术规范)、Feature List(功能特性列表)和各 SSTS (Subsystem Technical Specification,子系统功能规范)。 架构设计阶段的主要工作是“用框图描绘出要做什么样的车”。主要工作是进行功 能分配和网络拓扑设计。 系统设计的主要工作是“告诉供应商应该如何去做”。具体包含网络通信设计、硬 件信号设计、电源系统选型设计、电气原理设计

4、、电源分配和接地系统设计等工作。 三、 功能安全 ISO26262 标准第一版发布于 2011 年,适用于总重不大于 3.5 吨的量产型乘用车。 这一标准主要针对汽车上的 E/E 系统提出,目的是使得符合该标准的车上“不存在不 可接受的由 E/E 系统失效所导致的风险”。 ISO26262 标准包含 10 个部分,其中跟汽车 V 模式开发流程相关的是概念阶段(第 3 部分)、产品开发系统级(第 4 部分)、产品开发硬件级(第 5 部分)、产品开发软件 级(第 6 部分)、以及生产和运行阶段(第 7 部分)。在这几个阶段中,跟汽车制造商 紧密相关的则是概念阶段(第 3 部分)。 概念阶段的主要工

5、作包含:相关项定义、安全生命周期初始化、HARA(Hazard Analysis and Risk Assessment,危害分析和风险评估),以及提出功能安全需求并进 行需求分配。相关项定义描述整车有哪些功能,功能之间的接口、法律法规要求、环 境约束等,安全生命周期初始化的主要工作是识别这些功能是全新开发,还是在原有 的实现方案上进行修改。如果是全新开发,则执行完整的安全生命周期,如果是修改 后复用则需要对安全生命周期进行裁剪。HARA 主要是识别不同驾驶情境下功能故障 (malfunction) 在整车级别造成的危害,并且通过评估危害事件的严重性 S、暴露率 E 和可控性 C 得到危害事件

6、的 ASIL 等级(Automotive Safety Integrity Level,汽车安全 完整性等级,分为,四个等级,是最低等级,是最高等级),从而得 出 SG(Safety Goal,安全目标)及其 ASIL 等级。 四、 E/E 系统开发流程中的功能安全1) 需求定义阶段中的功能安全工作 a) SSTS 与 HARA 分析 Feature List 定义清楚之后,需要对这些 Feature 进行进一步细化,即形 成详细的 SSTS。比如 TPMS SSTS(胎压检测子系统功能规范)。与 Feature List 比,SSTS 对功能的定义会更加详细,一般需要描述清楚该 子系统与外部

7、的关联关系,比如需要输入哪些总线信号(比如车速信号), 哪些硬线信号(比如点火钥匙开关信号),输出哪些总线信号(比如轮胎 压力过低报警信号),哪些硬线信号。还需要列出更细节的功能点,比如 轮胎压力过低报警、轮胎温度过高报警、轮胎压力值显示、轮胎温度值显 示、轮胎快速漏气报警、左右轮失衡报警等。在 SSTS 初步完成之后,就 可以进行相关项定义,如果是全新开发,下一步是进行 HARA 分析。HARA分析完成后,可以再对 SSTS 进行完善,增加 SG。比如轮胎压力过低报 警功能,其功能故障为:轮胎压力过低报警不工作,相关的驾驶情景为高 速行驶,高速行驶的暴露率 E4, 如果高速行驶的时候胎压过低

8、,但是没有 报警,有可能发生爆胎事件导致严重车祸,严重度为 S3,驾驶员来不及 做任何反应,所以可控性为 C3,根据 ISO 26262 标准的风险矩阵得到此 危害事件的风险为 ASIL D,那么安全目标是避免胎压过低报警不工作, ASIL D。那么对于轮胎压力过低报警功能,就增加了一个功能安全需求。 2) 架构设计阶段中的功能安全工作 a) 功能分配、网络拓扑设计与功能安全概念 功能分配与网络拓扑设计过程比较复杂。需要权衡汽车制造商的总体需 求、各供应商的现有解决方案、总线负载率等因素,因此需要同时进行。 换言之,功能分配完成,则网络拓扑设计完成。由于 HARA 分析得出的 SG 已经包含在

9、 SSTS 中,所以功能安全需求在这一过程中随 SSTS 分配 而分配。被分配到的控制器,就继承了 SG 及其 ASIL 等级。此时,可能 就会存在一个 SG 被分配给多个控制器实现,或者一个控制器实现多个 SG 的情况。同时,功能安全也会影响功能需求的分配,如果一个控制器 大部分功能是 QM,只有一个或者很少的功能是 ASILD 等级的,那么可 以考虑把这个需求分配给已经分配了 ASIL等级的控制器。这样可以节 省成本,因为高 ASIL 等级意味着高成本。 另外,这一阶段还需要在通信系统相关文档中对功能安全相关的信号 进行说明,以便后续网络设计时,增加对应的功能安全机制。 3) 系统设计阶段中的功能安全工作 a) 网络通信设计中的功能安全 网络通信设计除了要保证常规通信、诊断、网络管理和标定需求,还要重 点考虑跟功能安全相关的总线通信信号。设计这类信号时,需要增加计数 器(Counter)、超时监测(Timeout monitoring)、数据 ID(Data ID)和 CRC 等安全机制。 五、 E/E 系统设计和功能安全服务 1) 标杆车解析服务 2) EEA 设计咨询 3) 功能安全咨询 4) 功能安全认证

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 建筑/环境 > 综合/其它

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号