E-Gas 知识梳理

“ 学习E-Gas 6.0 版本，域控，电机，项目功能安全设计参考”

参考文件 6.0

专业术语

• driving cycle

在传统车的角度指的是发动机启动/停止之间的操作时间，对于纯电动来说由BMS指定。作为域控可以通过报文来解析获取该信息。

• error or a single error

在需要考虑的特性里面至少有一个不能完全满足则可以定义为 error or a single error

• error

如果在下一个driving cycle没有发生，并且驾驶员或者是控制器也没有检测到相关故障，则这个error需要被定义为 潜在的error

• double error

需要定义为两个error，都发生几乎在同一时刻发生,并且这两个故障没有因果关系

• dual error

需要定义为两个single error，都发生(时间间隔超过一个很短的时间),并且这两个故障没有因果关系

• fault detection

当相关系统参数的超过允许偏差，导致不满足至少一个有关所考虑单元的要求特性的要求。这里设定一个检测时间。来减少误判，如果在这一事件内被检测到 则定义为已检测到错误。

• failure effect

需要在无故障下和有故障下根据系统的具体特性偏差来指定。

• failure reaction

在发生故障后，开始一套完整的手段，响应，来减少故障带来的影响，将破坏降低到一个被允许的限度。

• Controllable failure reactions

       ○  响应时间

       ○  整车行为限制，扭矩，转速，加速度等

• Raw signals

       ○  硬件寄存器采样的数字信号或者模拟信号

       ○  总线当前的没有被更改过的数据

• Reset

       ○  SW reset 被软件控制的初始化 判断影响范围 （ram, rom, etc)

       ○  HW reset 被硬件初始化  判断影响范围(看门狗，上下点，等等)

开发指导基本准则

• 优先考虑保护生命，声明作为最重要的考虑点。
• 能用可靠性解决的不要使用退而求其次的备用方案。可靠性优先于备份功能。
• 检测机制应该独立于功能，并且尽可能的独立于驾驶员的反应。
• 系统监控包括故障响应，需要简单的，并且可控便于管理的。
• 系统设计应当使single error， error 发生或者同时发生时系统反应时可控的。监控的相关信号路径应该是从传感器，到执行机构，到功能层面都要被监控
• 就高系统可用性来说，应争取阶段性错误反应。
• ”confirmed defected", "explicit detection", "assumed defected"，当一个故障在被检测到后，过了系统定义的次数或者时间后变成了"explicit detection"。在reaction执行之前都被认为 "assumed defected"。
• 适当的reaction需要设计，当系统处于 "assumed defected"阶段。当然在”confirmed defected"这时候reaction是必须的。
• reset这种故障响应，需要视情况而定，必须是可控的情况下。避免很多不连续的情况发生或者导致系统不连续的情况发生。
• 当系统不受控制，或者达不到可控的范围，这时候可以请求停机。这里的停机指的是将车辆请求到一个功能安全定义的安全感状态。
• 信号传输，发送方需要保证信号的有效真实完整性
• 当error发生，或者一系列的errors发生，系统出现了不可预测的响应，这时候需要提醒驾驶员。必要的时候改变驾驶形式。
• 监控功能需要有较高的鲁棒性，简单性
• 在每一次driving cycle钱需要进行关断路径测试，检测其有效性。和科目三驾驶员绕车转一圈一个意思。
• 当检测到电源有问题后，关断路径的检测依然应该是可用的。需要对电源进行监控，避免损坏其他部件。
• 安全理念需要遵循ISO26262

系统定义

概念从下图简单系统定义进行说起

功能安全设计的最开始需要定义清楚每个部件的边界，以及系统边界图。

有了完整的系统边界图，才对下面的安全分析有方向性，和目标性。

Hazard 和 Risk 分析

作为Hazard 和Risk 分析的一部分，分析了典型驾驶情况下系统的行为。基于上面的系统做了个简单的分析定义。并得出一下结果。这是从最顶层的分析结果。

Safety Goal

• SZ-01 Prevention of unintended acceleration → ASIL B
• SZ-02 Prevention absence of acceleration → QM
• SZ-03 Prevention of unintended deceleration → QM
• SZ-04 Prevention absence of deceleration → QM

从上面分析，无意识加速时需要考虑的。需要被监控的。并且需要定义一个fault tolerance time(fft)

下面的概念，以及设计都是为了达到SZ-01这个 GOAL 来实施的。

功能安全概念

分析哪些部件可能导致车子无意识加速

• 错误的扭矩

扭矩来自于哪里发动机，电机，扭矩监控出问题，执行件出了问题。

所以要对下面的component 进行一下安全要求(safety requirement)

• sensor

在捕获信号后，可对传感器信号(例如驾驶员加速踏板需求)进行合理性检查。

• actuators

执行器(A)在捕获执行器信号后，可以对执行器信号(例如油门位置)进行合理性检查

• Engine control unit

       ○  可以检测并确认不允许的高驱动扭矩设置

       ○  并将系统作为故障反应带入安全状态

       ○  安全概念采用了中央功能监控(2级)的理念。

       ○  发动机控制单元检测传感器系统故障。

       ○  发动机控制单元检测执行器故障。

       ○  在发动机控制单元中实现了安全概念

Central 功能监控:

• 无论功能级别(1级)如何，被监控的功能都应在功能监控级别(2级)中进行计算，并在发生错误时将其控制在可控范围内。
• 独立开发确保系统错误不会对功能层(第1层)和监控层(第2层)产生相同的影响。应在控制单元中实施附加措施，以验证所应用ECU硬件的完整性。
• 应确保位于1级和ECU-HW中的错误不会对2级产生未被发现的影响。

技术实施

监控概念

System Overview Electronic Control Unit (ECU)

• level1
• 功能层。
• 一级包含发动机控制功能，即实现所要求的发动机扭矩，组件监控，输入、输出变量诊断和控制系统反应应检测到故障
• level2
• 功能监控级别
• 第2级检测第1级功能软件的缺陷过程，例如通过监控计算扭矩值或车辆加速度。当发生故障时，触发系统反应。
• level3
• 控制器监控级别
• 监控模块应是功能控制器，它在问答交互过程中测试正确执行的程序
• 下面是最经典的三层架构图

当然在新版的图里面更新了锁步核的使用。如下图LC

ECU Level 1层的功能

这里需要梳理清楚ECU 包含了哪些Level 1的功能，这里简化一下，简单列几个

需要包括

• 所有的Level 1 层的功能
• 对监控从相关诊断的输入，输出定义

sensor components

• 加速踏板传感器

...

Actuator components

• 油门阀

...

ECU system component

• 扭矩请求单元

...

硬件特性以及诊断需求

这里需要列出上面需要被监控的components 的

• 特性
• 诊断的points
• 检测的方式
• 故障的描述等等

general requirement of level2 function monitoring

• 监控L1层功能
• 对于具有扭矩监测的系统，第2级的中心部分应是单独计算的“允许发动机扭矩”和“实际发动机扭矩”之间的比较。
• 2级加速监控系统的中心部分应该是单独计算的“允许车辆加速度”和“实际车辆加速度”之间的比较。
• 监测第1级故障反应，如果L2不能单独产生故障反应。
• 拥有周期性监控的内存区域计算程序流控制

举个Level 2层监控加速度的例子。

基本原理就是实际的和可能的/合理的/设计的计算进行对比。就得出了L2层的结果。

其他的一些monitor 也是使用类似的机制。这里不进行一一截图。截一张官方给的具体示例图监控加速度。

这一整套需要从最初开始的传感器，一直到实际的车速扭矩等信息的采集。整条链路需要从最上层车的级别去分析，然后深入到最终实现车运动这个动作的部件的角度来分析。

就比如从最上端的理论支撑，哪些部件涉及到。

直到最下面执行“动作”的部件如果运作。都是需要考虑。

下图为驾驶员的动作到功能层以及监控的传递。

Level 3 Controller Monitoring

• 控制器监控是指软件和硬件结构之间的相互作用。
• 它可以检测功能控制器(控制器核心，RAM/ROM中受影响的区域)的故障操作。
• 必要的检查可以作为软件功能(例如存储器测试值和补码)或控制器内部错误检测硬件或两者的组合来执行。
• 只有在以下情况下才允许由控制器内部错误检测硬件进行检查
• 控制器内部错误检测硬件在当前周期内的工作能力
• 应通过对潜在缺陷的测试来验证(例如，在关机路径上渗透ECC)。只有在完成此试验后，才允许发动机启动。
• 控制器内部错误检测硬件的配置是周期性测试的(例如激活ECC)。

一般有一下方面

ROM检测

检测QA机制

• 程序流监控
• 指令集测试
• 功能指令集
• 原子指令集
• 控制器内部故障

采样的检测

• AD转换 等等

reset 系统特性

下图为综合L1,L2,L3 直至整车reaction的路径图。每一个步骤都需要下一层的保障。

可以说L3层更多的是机制本身的实现与确保。对板本身的监控与测试。

系统错误响应

故障反应应考虑以下原则

• 必要的合理性取决于OEM的具体项目要求
• 从故障检测到系统反应开始的最大持续时间应定义为特定故障。(例如扭矩监测基准= 500ms)等等

希望对大家有一点点帮助。谢谢大家阅读

文章转载自公众号：汽车与基础软件