|
我们接着前两期的专题继续，上一次我们讲到了功能安全需求FSR是如何提出来的。FSR完成以后，我们会做功能安全系统设计，其中很重要的工作输出是技术安全需求(Technical safety requirements)文档。 对于扭矩安全这个话题，从避免非期望的车辆加速度这个Safety goal出发，可以推导出很多条功能安全需求FSR。比如对于“HCU应该实现传动扭矩的监控”这条FSR而言，如何展开这条技术需求，并生成下探到具体细节的技术安全需求呢？ 3-level监控结构 提到Monitoring, Three level监控结构是必须要学习和了解的。下面这张图节选自'邪恶联盟(宝马、奔驰、奥迪等)'的<Standardized E-Gas Monitoring Concept for Gasoline and Diesel Engine Control Units>这篇文献。网上可以直接download, 后面有机会我们再仔细研读这篇文章。 对于Torque monitoring这个安全需求，如何在技术安全设计上，运用三层监控架构呢？ 1. Hardware design and selection 控制系统是软硬件结合的东西，软件设计的非常可靠，编程规范做的很牛。但是承载代码的硬件不可靠，经常死机、程序跑飞。你所设计的系统也不会是一个可靠的系统。 所以对于Torque monitoring的安全需求，第一步是要设计并选择合适的硬件系统。双核MCU+独立的系统基础芯片SBC是目前的主流架构，其中MCU中运行控制代码，SBC芯片负责处理器供电、看门狗、硬件监控等功能。 双核MCU中的双核是啥意思呢？我们以TMS570LS0x32这款主控芯片为例来学习下。这款芯片是一个典型的1oo1D双核架构系统，具有以下特点：
在锁步模式下(Lock step)，同时将同一组输入发送到这两个内核，然后这两个内核在相同的时钟周期内执行相同的计算，定期比较结果，检测是否发生了故障(无论是瞬时故障、间歇性还是永久性故障)。一旦输出不匹配，通常会标记故障并执行处理器重启。延迟锁步是锁步的一种，其中一个内核的输入延迟了N个时钟周期，另一个内核的输出也延迟了相同的时间，然后比较结果。用这种方法，可获得时间分集。由于一个内核在N个时钟周期后将执行相同的运算，冲击这两个内核并以相同的方式影响其功能的噪声脉冲的概率将大大减少。 查询TMS570LS0x32芯片手册，可以看出CPU1和CPU2差了2个时钟周期。 MCU中的CPU1和CPU2获取相同的输入信号，并执行相同的计算逻辑，定期比较运算结果，那硬件上就需要一个硬件比较器。对于TMS570LS0x32而言，内置内核比较模块(CCM-R4),如下图所示。 CCM-R4模块有如下几种工作模式：
不同工作模式与寄存器配置信息如下表所示 下面我们说一说系统基础芯片(System baisc chips)，SBC不仅可以为系统供电，还包含看门狗、错误信号监控、存储器CRC等多种安全功能。为了方便理解SBC是个什么东东，我们以德州仪器的TPS65381芯片为例子进行学习。 TPS65381是一个32pin芯片，可以为多个MCU，CAN收发芯片以及外部传感器供电。除此之外，该芯片还具有监控和保护功能，包括：具有触发模式和问答模式的看门狗、MCU错误信号监控器、针对内部振荡器的时钟监控、针对时钟监控器的自检等功能，典型应用电路如下图所示。 TPS65381作为一个高可靠性的供电芯片和硬件监控芯片，需要与主控芯片配合使用。下图为65381和TMS570配合使用时，引脚连接示意图。需要注意的是，65831内部集成了Error signal monitoring(ESM)模块，若TMS570 Core compare module检测出错误时，会把Error信息上报给ESM模块，65831会执行Reset微控制器的操作。 其中和TMS570相连的Pin脚解释如下： VDD5：直流稳压器5V输出 VDD3/5：直流稳压器3.5V输出 VDD1: MCU内核供电 DIAG_OUT：诊断输出引脚 ENDRV：使能输出信号 NRES：微控制器复位输出信号 ERR/WDI：来自微控制器的错误输入信号和看门狗触发信号 NCS：SPI片选信号 SCLK：SPI时钟信号 SDI: SPI串行数据输入 SDO：SPI串行数据输出 设计合适的硬件架构，并选择适合的主控芯片和系统基础芯片，构成了扭矩监控逻辑运行的硬件基础。上文以德州仪器公司的两款非常有代表性的芯片为例，讲述了双核锁步架构的控制器硬件设计。 2. Software structure design 软件架构设计是一个非常难的事情，牵扯到底层的软件执行的顺序、操作系统任务调度等。控制器层面如何执行监控模块，功能层和监控层的运行时序上有什么区别，这些问题挺难回答的，暂时我也不是特别清楚。Anyway这个问题问题我们先留在这，后续随着学习的深入和认知的加深，我们再试着回答这些问题。 但是简单一点，我们可以尝试去分析监控软件结构设计(其实我更喜欢静态视图这个称呼)。双核锁步架构的控制器硬件、功能层软件(APP SW)和监控层软件(Monitoring)分布如下图所示。Core1和Core2执行相同的功能软件和监控逻辑。 坦白来说，扭矩监控这个Topic，小编以前也没有接触过。最近download了一些专利和企业发的论文，从中整理出了关于扭矩监控的软件结构，如下图所示。通用一点说：扭矩监控主要包括：扭矩容量监控、扭矩和监控和输出扭矩监控。有了简单的扭矩监控结构图，下一步要分析具体的扭矩监控逻辑，形成扭矩安全的技术安全需求。 3. Detailed monitoring logic design 涉及到具体的扭矩监控逻辑细节，有很多种实现手段。小编分析了几篇典型的专利，这里我们来学习下他们的成果。 <混合动力汽车的扭矩监控方法和装置>--上汽集团，2014年12月 扭矩监控的流程图如下图所示。若作用于车轮端的实际扭矩值超出允许的稳态扭矩限值，整车产生超限加速度。超限加速度积分产生超限速度和超限位移，若超限速度/位移超出安全阀值，整车进入安全状态，执行降扭或断油等操作。 <新能源汽车的扭矩安全控制方法>--北汽新能源，2015年5月 具体的实现如下流程图所示。该专利描述了2层扭矩监控方法，第一层监控需求扭矩计算逻辑、第二层比较动力源实际输出扭矩和轮端估算扭矩。最终仲裁是否出现扭矩错误，并做出对应的响应措施。
<一种电动汽车的扭矩监控系统以及方法>--长安汽车，2013年7月 具体实现如下流程图所示。该专利根据车辆行驶工况，进行电机控制器扭矩监控，主要包括：车辆行驶工况判定模块、系统电流监控模块、系统电压监控模块、电机控制器扭矩反馈计算模块等。
具体实现如下流程图所示。
在完成硬件架构设计和扭矩监控软件的设计之后，需要完成对应的技术安全需求文档(TSR)。对于功能安全系统工程师而言，需要写出尽可能详细的TSR文档。硬件工程师和软件工程师基于TSR文档，做软件分解和硬件分解，那就是ISO26262第五章和第六章的部分了。 比如'HCU应该实现扭矩监控'这条需求，软件工程师需要作出更详细的逻辑文档，比如：如何实现扭矩计算监控、使用哪些冗余信号、扭矩监控滤波器如何设计等。 本期专题我们分了三次，系统性的讲述了扭矩安全这个话题的功能安全实现与分解。但是这只是一个非常简单的入门案例，功能安全是一个非常庞大的系统工程。优秀的安全设计是需要下很多功夫、不断优化迭代的过程。后面我们继续功能安全的topic，学习变速器控制系统的功能安全知识。 |
|
|
