寻找供应商
广告
首页 > 汽车技术 > 正文

智能汽车车用基础软件平台关联技术

2022-09-25 17:59:10·  来源：汽车测试网  
　
在产品开发阶段，ISO26262 标准划分出了系统、硬件和软件部分。在系统开发部分，需要考虑系统的初始架构以及各种设计边界条件，结合系统层级的安全分析，更新系统架构，并定义出分配给硬件和软件的技术安全需求。在硬件和软件开发阶段，整体的开发流程参照 V 模型执行。以软件为例，在 V 模型的左半边，基于上游的软件技术安全需求以及软硬件接口规范文档，软件安全需求被定义出来，并和非安全相关的功能需求一起，作为软件架构设计的输入。在软件架构设计阶段，需要对架构进行验证（方法如：仿真、数据流分析等），并执行软件安全分析，再针对分析的结果定义并落实合理的安全措施。在详细设计阶段，每一个软件单元的接口和内部逻辑被设计，并遵循编码规范开发成代码。V 模型的右半边主要是针对 V 模型左半边活动的验证，通常会包括静态的代码分析和测试活动。在测试活动中，需要根据需求的 ASIL 等级使用相对应的测试用例定义方法和测试方法。需要强调的是，ASIL 等级要求越高，它对应的设计、归档和测试验证等环节所推荐的技术手段就越严苛。通过这样的方法，可以合理规避可能由人为引入的系统性失效。在软件和硬件被开发出来之后，需要将它们集成在一起，并在系统层级和相关项层级参照具体的需求和需求的 ASIL 等级执行相应的测试验证手段。

除此以外，ISO26262 标准还定义一些支持性流程（如：变更管理、配置管理等），来辅助功能安全开发活动的合理有序执行。标准还包含了功能安全审核的流程定义，来对功能安全开发的产物进行验收， 并确认产品是否满足量产的要求。

2.  ISO21448 汽车预期功能安全标准

ISO21448 作为ISO26262 的补充，它填补了ISO26262 中关于自动驾驶领域的功能安全分析的空缺。SOTIF（Safety Of The Intended Functionality ）的诞生也是 ADAS 与自动驾驶普及大背景下的必然结果，它是预防不合理风险的一道防线。

ISO21448 预期功能安全标准重点关注的是 “预期的功能” 的安全性，即满足预期设计要求的功能所具有的安全水平，将设计不足、性能局限导致的风险控制在合理可接受的范围内。由于自动驾驶车辆运行场景条件的复杂性和未知性，自动驾驶功能即使满足设计要求，仍可能存在大量的安全运行风险。如何避免预期的功能所引发的安全风险，即为预期功能安全。

从安全性和已知性角度，将车辆运行场景分为已知安全场景、已知不安全场景、未知不安全场景和未知安全场景 4 个区域，如图 4.1-2 所示。在开发之初，区域 2 和区域 3 的比例较高，SOTIF 技术通过对

已知场景及用例的评估，发现系统设计不足，将区域 2 转化为区域 1，并证明区域 2 的残余风险足够低；针对区域 3，SOTIF 技术基于真实场景及用例测试、随机输入测试等，发现系统设计不足，将区域 3 转化为区域 2，同时基于统计数据和测试结果，间接证明区域 3 的风险控制到合理可接受的水平。由此 , 实现对已知和未知风险的合理控制，完成自动驾驶车辆系统的安全提升和发布。

图片

图4.1-2 自动驾驶运行场景分类及SOTIF开发、验证和发布演进

自动驾驶系统安全风险的一个主要来源是未知不安全场景区域，对其无法定义需求，也难以量化评价， 这成为全球自动驾驶安全开发领域的痛点，ISO21448 标准在此背景下诞生并于 2022 年 6 月发布，为此痛点提供方法支持。

ISO21448 标准给出了 SOTIF 开发流程，如图 4.1-3 所示，其中圆圈的序号代表标准原文各章节号：

图片

图4.1-3 SOTIF活动流程示意图

4.1.2  功能安全软件架构

1.  E-GAS 安全架构思想

汽车功能安全旨在把电子电气系统失效而导致的人身危害风险控制在合理范围内。下图 4.1-4 是常见的电子电气系统硬件构成图，一个电子电气系统的构成要素，除了图中可见的硬件外，也包含图中不可见的软件。

图片

图4.1-4 常用电子电气硬件系统

电子电气系统的失效，既包含由于软硬件设计错误引起的系统性失效，也包含由随机硬件故障引起的失效。根据系统架构，需要设计各种安全机制去预防和探测功能故障，并能够在故障发生时，避免或者降低危害的发生。这就需要一个强壮的功能安全软件架构来管理和控制这些安全机制，降低功能安全整体开发难度。

目前，E-GAS（Standardized E-Gas Monitoring Concept for Gasoline and Diesel Engine Con- trol Units）无疑是当前使用最为广泛的一个安全软件架构方案。虽然 E-GAS 最初只是针对汽 / 柴油发动机管理系统而提出的安全架构方案，但是经过简单的适配，也可以用于车身系统，变速箱系统以及新能源的三电系统等，具有非常良好的扩展性，应用非常广泛。

下图 4.1-5 是 E-GAS 的三层软件架构设计方案，从上到下，软件分为 Level1~3 总共三层，Level1 是功能实现层（function level），Level2 是功能监控层（function monitoring level），Level3 是控制器监控层（controller monitoring level）。该架构形成了很好的分层监视框架，并有效实现了功能安全分解， 通常采用 QM（ASIL X）+ ASIL X（ASIL X）的安全分解策略，即将功能实现软件（Level1）按照 QM 等级开发，功能冗余软件或安全措施（Level2、Level3）按照最高的要求等级 ASIL X（ASIL X）进行开发， 这样可以有效降低功能软件的安全开发成本。

图片

图4.1-5 E-GAS三层监视架构方案


(1) Level1 功能实现层


Level1 是功能实现层，完成具体的功能实现，比如对于电机控制器来说，这一层实现了将请求的扭矩转换为电机的扭矩输出。

   首页   下一页   上一页   尾页 
分享到：
 
反对 0 举报 0 收藏 0 评论 0
  • 汽车测试网V课堂

    汽车测试网V课堂

  • 微信公众号

    微信公众号

  • 汽车测试网手机站

    汽车测试网手机站

• ENCAP2026对撞后安全的要求（中） • 汽车智能座舱分级与综合评价白皮书
• 一文详解安全分析方法STPA：以自动紧急制动系统（AEB）为 • 新品上市 | Fusion-LN 数据采集的下一个飞跃
• 车规级V2X芯片- 汽车移动通信功能核心 • BEV端到端视觉论文合集|从不同的视角解析BEV感知技术
• 新能源汽车应用中的【夜视系统】与【雨夜系统】 • 汽车安全基础
• 极氪007电驱动系统拆解，看到了啥？ • 长安汽车申请具备单换热器的空调总成的车辆热管理系统专利
0 条相关评论
  • 广告
  • 广告

编辑推荐

最新资讯

  • 广告
  • 广告
沪ICP备11026917号-25