［摘要］ 转矩控制作为整车控制器（VCU）的核心功能，保证其安全性至关重要。为此，本文针对VCU非预期的转矩输出异常的问题，参考ISO 26262标准开展功能安全分析，并提出一种基于EGAS架构的转矩控制3层监控策略。首先，以VCU相关项定义为基础，通过危害分析与风险评估确定汽车安全完整性等级以及安全目标。其次，采用故障树分析方法导出功能安全要求以及技术安全要求。再次，针对安全目标，设计了基于AURIX TC275三核主控芯片与TLF35584电源监控芯片的功能安全机制。此外，通过3层监控策略分配CPU资源，实现转矩控制基本功能与监控功能的分离。最后，进行处理器在环测试，包括UDE调试、UDS诊断以及TLF35584安全状态控制测试。结果表明：该3层监控策略能够实现VCU转矩控制的基本功能并在出现故障时及时进入安全状态，从而达到安全目标。

前言

随着汽车不断向智能化、集成化方向发展，汽车电子电气系统的数量和复杂度不断增加［1］。为了保证复杂系统下汽车的整体安全性，国际标准化组织（ISO）于2011年正式发布了第1版道路车辆功能安全标准ISO 26262［2］，并于2018 年发布第2 版ISO26262［3］。根据ISO 26262标准中的定义，功能安全是指不存在由电子电气系统的功能异常表现引起的危害而导致的不合理的风险。

EGAS（electronic gas pedal）系统是电子油门系统的简称，由加速踏板、发动机控制单元、电子节气门以及传感器等组成。EGAS监控概念是从发动机控制系统抽象出来的概念，该监控概念将发动机控制系统分为3层，由德国多家汽车主机厂共同提出并制定相应指导文件［4］。EGAS监控概念的产生早于ISO 26262 标准，但后来EGAS 工作组根据ISO26262标准对监控概念进行了更新。

整车控制器（VCU）作为纯电动汽车的核心控制单元，负责解析驾驶员意图，并提供期望转矩给电机控制系统［ 5］。由于转矩控制是VCU的核心功能，直接关系到车辆的安全性，如果在车辆行驶中VCU输出非预期的转矩，将可能造成生命危害，所以提高VCU转矩控制的安全性成为一项必要而又困难的问题。熊再辉［6］针对VCU输出转矩过大的安全目标，结合EGAS安全架构，采用主芯片+监控芯片的硬件设计并调用硬件机制的软件安全组件，但其未涉及不同CPU核分配给不同层任务，存在耦合问题。吴凯［7］以车辆未按油门踏板控制的方式加速为例，设计EGAS监控系统并建模进行仿真测试，验证了监控系统的有效性，但其使用的TC1782主控芯片为单核处理器，故并未很好覆盖其所设计的3层架构中的每一层。吴静波等［8］针对避免非预期的转矩变化的安全目标，提出一种基于EGAS架构的多层监控策略，其以双核芯片MPC5744P为基础设计监控层，通过不同的核心分配实现基本功能模块与安全模块的分离，但其并未充分考虑处理器监控层软件部分相关的安全模块设计与测试。

对此，参考ISO 26262标准，本文针对VCU转矩控制的功能安全开展进一步研究，并以AURIXTC275主控芯片与TLF35584电源监控芯片为基础，提出一种基于EGAS 架构的3 层监控策略，将3 个CPU分别分配到3层架构中实现独立运行并充分覆盖3层，实现软硬件解耦。并设计了故障处理策略，使系统快速恢复或迅速进入安全状态。

本文结构如下：首先，参考ISO 26262标准进行相关项定义，然后通过危害分析与风险评估确定汽车安全完整性等级（ASIL）以及安全目标，进而导出功能安全要求以及技术安全要求；其次，提出3层监控策略并进行详细设计；最后，进行处理器在环测试，验证其能实现安全目标。

1　功能安全分析

1. 1　相关项定义

首先对VCU进行相关项定义，其目的是从整车层面对相关项进行定义和描述。VCU的主要功能描述为动力系统控制、信号采集、安全状态管理、电源管理、信号输出控制以及接口管理等。本文采用独立于环境的安全要素（SEooC）开发方式。SEooC假设的使用环境为相关项定义所界定的范围，VCU外部可以提供驾驶员请求的信息，且该信息达到所需的ASIL等级。针对VCU转矩控制功能，进行相关项定义，如图1所示。

1. 2　危害分析与风险评估

根据ISO 26262标准可知，危害与可操作性分析（HAZOP）适用于危害识别。由于HAZOP方法有助于结构化和系统化地检查相关项在整车层面的运行情况，故本文采用HAZOP方法识别危害。根据SAEJ2980［9］中的简化HAZOP方法，选取功能丢失、多于预期和少于预期3个引导词，故转矩功能异常表现映射到整车层面的危害为：非预期的车辆加速、非预期的车辆加速丢失、非预期的车辆减速和非预期的车辆减速丢失。

严重度（S）代表对一个特定驾驶场景中潜在伤害的预估，暴露概率（E）由相应的场景确定，可控性（C）衡量了驾驶员或其他道路交通参与者在所考虑到的运行场景中避免所考虑到的事故的难易程度。综合考虑严重度、暴露概率和可控性，最终通过图2确定ASIL等级。

本文选取常见的车辆运行场景，对VCU转矩控制功能进行HARA分析，结果如表1所示。

1.3　安全目标的确定

安全目标是整车层面HARA分析结果的最高层面的安全要求。由表1可初步得到VCU转矩控制功能的多个安全目标，又根据ISO 26262标准，可将类似安全目标合并为一个安全目标，并将最高的ASIL等级分配给合并后的安全目标［10］。因此，安全目标导出为“避免VCU 非预期的转矩输出异常”，对应ASIL C等级。安全状态为VCU复位并发出警报通知驾驶员，当复位无法消除故障时则中断转矩输出。此外，根据经验值以及满足VCU复位时间，将故障容错时间间隔（FTTI）设置为100 ms。

1. 4　功能安全要求

在定义每项功能安全要求时，可以考虑运行模式、FTTI、安全状态和功能冗余等。为了制定一套完整有效的功能安全要求，故障树分析（FTA）、失效模式与影响分析（FMEA）等安全分析方法可提供支持。由于FTA方法能系统分析故障原因以及可使用易于理解的图形化表达方式，故本文采用FTA方法进行安全分析，以VCU非预期的转矩输出异常为顶事件，自上而下进行分析，寻找违反安全目标的底层故障事件，如图3所示。

从安全目标导出功能安全要求，并将其分配到系统架构设计和外部措施中，如表2所示。

1.5 技术安全要求

技术安全要求（TSR）是实现FSR必要的技术要求，目的是将相关项层面的FSR细化到系统层面的TSR。根据FSR导出TSR，如表3所示。TSR应分配给软件或硬件作为实施技术的系统架构设计要素，故本文进行了软硬件类型分配。

2　面向功能安全的软件架构设计

根据ISO 26262中软件架构设计部分的要求，软件架构设计应以层次结构的形式表示软件架构要素及其交互方式。另外，考虑到EGAS概念提供了一种经典的汽车功能安全系统架构方案并能实现分层监控［11］，故本文基于EGAS架构设计了一种VCU转矩控制3层监控策略。由于不同的芯片针对3层架构存在不同的移植难点，为了充分覆盖3层架构以及提高每一层的独立性，故本文将以AURIX TC2753核主控芯片以及TLF35584电源监控芯片为基础，较好符合所设计的3层架构。

2. 1　AURIX TC275 与TLF35584

AURIX TC275（简称为TC275）是采用32 位的TriCore处理器架构，3个CPU都能以独立的方式执行任务。TC275的安全管理单元（SMU）是安全架构的核心组件，提供了一个通用接口来管理TC275存在故障时的行为。SMU集中了与不同硬件和软件安全机制相关的所有警报（Alarm）信号。Alarm信号可以通过故障信号协议（FSP）向外部环境报告内部故障，以控制系统的安全状态［12］。默认的故障信号协议是一个错误引脚（Error Pin）。

TLF35584是为安全微处理器供电的电源芯片，具有带复位功能的独立电压监控以及可配置的功能看门狗。通过与主控芯片的SPI接口，可以对该芯片进行灵活的配置和控制［13］。可以作为独立的监控组件，监控TC275软件行为。

2. 2 3 层监控策略

以EGAS3层架构为基础，对VCU的转矩控制功能设计3层监控策略，3层架构分别为功能层（Level1）、功能监控层（Level 2）和控制器监控层（Level 3），如图4所示。

功能层（Level 1）主要是实现基本的转矩控制功能，依据踏板位置、挡位、车速、电机实际转速等信息解析驾驶员需求，同时计算目标转矩，最后输出控制信号。此外，还存在一些诊断功能，例如对踏板信号的合理性检查等，基于诊断结果，Level 1也将执行相应的故障响应。

功能监控层（Level 2）通过冗余的软件逻辑监控Level 1。整体的思想是独立于Level 1的另一种算法估计驾驶员的目标转矩，同时依据电机控制器反馈给VCU的实际电机转矩输出，将目标转矩与实际转矩进行比较［4］，如果两者的差值大于预定义的阈值并持续超过一定时间时，则会进入安全状态［TSR-06］。另外，使用第2路独立的信息采集与处理路径作为Level 1 的冗余［TSR-01、TSR-02、TSR-04、TSR-05］。

控制器监控层（Level 3）由两部分组成：硬件上独立的监控模块和功能控制器中的监控软件。本文将TC275作为功能控制器，TLF35584作为监控控制器，TC275 与TLF35584 通过SPI 进行通信。TLF35584定时向TC275提问，TC275在规定时间内回答［TSR-08］。TLF35584如果得到错误答案，将会重复发送相同的问题并启动故障计数器。为检测TLF35584的潜伏失效，TC275会定时发送一个错误答案以测试TLF35584的监控功能是否正常。此外，还包括了电压监控［TSR-07］、内存测试［TSR-03］、关断路径测试和A/D转换测试等。

TC275的3个CPU分别是两个锁步CPU（CPU0和CPU1）和一个非锁步CPU（CPU2）。此外，CPU0是高效率、低功耗架构，CPU1和CPU2是高性能架构。根据本文设计的3层架构，现对3个CPU进行分配。首先，由于CPU0是高效率、低功耗架构并且带有锁步核，故将其分配给Level 1用于实现基本的功能，保证转矩控制功能高效执行，同时降低功耗、提高可靠性。其次，由于CPU1是高性能架构并且带有锁步核，故将其分配给Level 2用于实现Level 1的监控功能，确保目标转矩与实际转矩的对比校验能够快速执行并通过锁步监控提高容错能力。最后，由于CPU2是高性能架构，故将其分配给Level 3软件部分，确保A/D 转换测试、内存测试等更快速执行。

2. 2. 1　Level 1设计

在保证踏板转矩需求有效的前提下，例如电机使能、不处于充电状态和车辆处于Ready状态等，踏板转矩需求可根据踏板开度、挡位、车速和电机实际转速等确定。

计算踏板转矩的方法有多种，例如加速度法、动力学模型法、查表法等，根据实际项目中的应用，为了提高计算效率以及简化计算过程的目的，Level 1选择查表法计算踏板转矩。电机实际转速由MCU发送给VCU的CAN报文获取，而电机实际转速下对应的最大转矩通过查表线性插值法确定，然后将获得的最大转矩与踏板开度相乘即可得到踏板转矩。

当Level 2 无法独立执行故障响应时，须依靠Level 1实现并对其进行监控。Level 2软件还须布置根据相关项定义划分的界线，本文将认为踏板转矩即为目标转矩。

2. 2. 2　Level 2设计

Level 2用不同于Level 1的目标转矩计算方式，出于简化以及相比于查表线性插值法更高精度的目的，使用拟合曲线的方法获取电机实际转速下的最大转矩。将计算出的目标转矩与电机控制器反馈给VCU的电机实际输出转矩进行比较，当实际输出的转矩与目标转矩的差值超过5%［14］时启用不同的故障响应，如表4所示。

当Level 2 无法独立执行故障响应时，须依靠Level 1实现并对其进行监控。Level 2软件还须布置检查点来支持Level 3进行程序流监控，同时Level 2的内存区域将被Level 3周期性监控。

2. 2. 3　Level 3软件设计

对Level 3中的软件部分设计安全功能模块，主要有如下内容。

问答监控。采用TLF35584的功能看门狗功能，TLF35584 提出问题并期望在定义的时间段内从TC275获得正确的答案，如果回答错误或在错误时刻收到正确回答，都认为是错误回答。此外，为了测试TLF35584的功能处于正常状态，TC275会在一定的时间间隔内给出错误答案。错误的回答都将使功能看门狗故障计数器增加，当计数超过阈值时，TLF35584将触发VCU复位。

关断路径测试。主要为确保在出现故障时能安全关断。每次车辆启动前都要测试一次，只有在测试通过后才可以授权电机运行。如果关断路径出现故障，VCU将会一直处于复位状态，直到能授权电机运行才会解除复位状态。

A/D 转换测试。主要是确保A/D 转换功能正常，如果A/D转换功能出现故障，将会导致驾驶员转矩需求解析出现异常，此时将复位TC275并排除故障，否则车辆不能启动。

内存测试。确保TC275内部RAM和FLASH模块能正常工作，提高TC275的可靠性和安全性。在每次车辆启动之前，都应该执行一次RAM和FLASH测试，只有检查无故障时才允许启动。在内存测试中至少需要检测出寻址错误、地址缓冲区溢出错误以及位翻转错误。

2. 2. 4　Alarm事件

TC275的SMU具有灵活的Alarm配置功能。本文针对所设计的3层控制架构，从软件和硬件层面设置相应的Alarm事件，如表5所示。

2. 2. 5　统一诊断服务

统一诊断服务（UDS）是ISO 14229标准［15］的一部分，该标准定义了不同的诊断服务和消息格式，允许诊断工具与车辆的电子控制单元交互。

当VCU检测到故障发生时会将相应的故障码进行存储，该故障码就是诊断故障码（DTC）。由于读取DTC信息服务允许客户端读取服务器内存储的DTC状态信息，故本文使用读取DTC信息服务，服务ID为0x19，用于获取VCU故障时存储的信息。0x19服务定义了28 个子功能，根据不同的子功能可以获取不同的诊断信息，本文使用通过DTC状态掩码读取DTC信息的0x02子功能。

通过DTC可以反映出故障位置和故障类型，本文遵循ISO 15031-6 协议［16］定义DTC 格式，采用两个根字节与一个故障类型字节的编码方式，现将SMU故障的DTC定义为P102046。

2. 2. 6　Level 3硬件设计

TC275 的Error Pin 与TLF35584 的ERR 引脚相连，当发生Alarm 事件时，TC275 的SMU 通过ErrorPin 向TLF35584 报告内部故障。当TLF35584 的安全状态信号SS1和SS2都为低电平时，将从硬件层面使VCU一直处于复位状态。

Alarm 分为软件Alarm 和硬件Alarm。当Alarm发生时，软件Alarm 需要在软件中调用函数设置Alarm，而硬件Alarm则由芯片硬件自检测自动设置Alarm并触发后续动作。当Alarm产生后将进入中断，首先调用函数清除Alarm状态，然后调用函数释放FSP。其次，将故障计数加1并存储到已定义的Flash中，其中故障计数的初始值为0。再次，调用设置DTC 状态函数将已定义的SMU 故障设置为FAILED 状态。最后，将触发VCU的软件复位。而当故障计数的值超过10次并再次出现Alarm时，进入中断清除Alarm状态后将会进入While死循环，等待SS1和SS2信号从高电平变为低电平，最终使VCU一直处于复位状态。

ERR引脚正常状态下为高低电平切换的信号，当停止高低电平切换并保持低电平或者高电平时将被检测为错误。ERR引脚的反应可以分为立即反应和恢复延迟反应两种，本文将利用TLF35584芯片的恢复延迟反应机制，作为Level 3监控模块的安全状态控制。

当Alarm 发生时，ERR信号停止切换并保持低电平。在超过检测时间图片后，将会产生中断指示恢复延迟时间图片开始。如果Alarm发生的时间超过图片，即在到达图片之后，图片将被拉至低电平，然后在可选延迟时间图片 后图片被拉至低电平，如图5所示。而如果Alarm发生的时间短于图片，即在到达图片之前ERR信号重新开始切换，则SS1 和SS2将一直保持高电平，如图6所示。其中，图片配置为10ms，图片配置为0 ms，即SS1和SS2引脚情况相同。

3　处理器在环测试

根据ISO 26262中软件层面的要求，本文对所设计的3层监控架构进行处理器在环（PIL）测试。

3. 1　代码编写与烧录调试

首先，通过Matlab/Simulink 分模块搭建Level 1和Level 2的控制策略，并借助Simulink的代码生成工具Embedded Coder生成代码。

其次，使用HighTec 编译器编写需要烧录到VCU中的HighTec工程，并将Simulink生成的代码配置到其中。生成代码时将所有的模块生成在一个函数中，存在很深的耦合关系，为了达到分层的目的，需要对函数进行解耦。在解耦之后分为用于Level 1和Level 2的两个程序代码段，Level 1对应的函数在CPU0中调用，而Level 2对应的函数则在CPU1中调用，两者调用的周期都为10 ms。

最后，使用PLS/UDE 工具将HighTec 编译的代码烧录进VCU并调试。在对应Level 1和Level 2的两个函数中打断点均能到达，同时观察多个变量也均为正常值，表明程序已经在VCU中成功运行。

3. 2　Level 1 与Level 2 测试

通过使用UDE中的Time/Value Chart功能来观测踏板转矩、电机实际转矩以及限制的车速等变量随时间的变化情况。

以加速踏板转矩为例，比较Level 1和Level 2的两路加速踏板转矩值，结果如图7所示。从图中可知，两路加速踏板转矩值基本一致，偏差在2 N·m之内，故可以使用Level 2计算的踏板转矩作为Level 1的冗余计算。

下面进行故障注入测试，验证Level 2出现故障时是否会按照表4中的定义进行响应。故障注入的方式为在采集到踏板开度之后进行增益处理。为了覆盖3种故障，选取3种故障范围中的典型值，现设置：故障注入1为3级故障，即增益选择为1. 08倍；故障注入2为2级故障，即增益选择为1. 15倍；故障注入3为1级故障，即增益选择为1. 30倍。结果如图8所示，在正常状态下，踏板转矩与实际转矩基本一致，同时限制的车速为140 km/h。当为故障注入1时，计算可得电机实际转矩与踏板转矩的差值为8%，车速限制为80 km/h，即3级故障；当为故障注入2时，计算可得电机实际转矩与踏板转矩的差值为15%，车速限制为30 km/h，即2级故障；当为故障注入3时，计算可得电机实际转矩与踏板转矩的差值为30%，车速限制为0 km/h，即1级故障。综上，故障注入时均能及时反应并符合要求，故测试通过。

3. 3　UDS 诊断测试

本文采用基于ISOLAR AUTOSAR 配置工具和CANoe总线检测工具进行UDS诊断测试。首先，用ISOLAR AUTOSAR工具对DTC进行配置，将DTC的严重度配置为出现故障立即检查（系统故障等级），如图9所示。此外，配置完成之后须生成代码。

其次，将生成的代码移植到HighTec工程中，其主要是一个设置事件状态函数，当有SMU的Alarm事件发生时，这个事件状态函数将SMU故障设置为FAILED 状态，而SMU正常状态下该事件状态函数将SMU故障设置为PASSED状态。

最后，使用CANoe 进行UDS 诊断。当有Alarm事件发生时，输入服务请求为0x19，0x02，0x08，得到的肯定回答为0x59，0x02，0xFF，0x10，0x20，0x46，0x2F，其中0x102046就是DTC，代表SMU出现故障，而0x2F代表DTC的状态，表示该DTC测试已经完成并检测出DTC故障码。

3. 4　TLF35584 安全状态控制测试

为验证TC275 的SMU 发生Alarm 时TLF35584的安全状态控制反应，现对Alarm发生时间短于恢复延迟时间以及Alarm发生时间超过恢复延迟时间两种情况进行测试。

当SMU发生表5中所示的Alarm时，针对Alarm发生的时间超过恢复延迟时间的情况，使用示波器测量ERR引脚以及SS1和SS2引脚，结果如图10所示。黄色线代表ERR，绿色线代表SS1和SS2。从图中可知，当SMU处于正常状态时，ERR引脚为50%占空比的方波信号，SS1和SS2为高电平。当Alarm发生时ERR引脚停止高低电平切换并拉至低电平。SS1与SS2在延迟一定的时间后拉至低电平。由于与图5相对应，故测试通过。

Alarm发生的时间短于恢复延迟时间的情况如图11 所示。黄色线代表ERR，粉色线代表SS1 和SS2。而绿色线代表一个IO电平的拉高拉低来演示检测时间与恢复延迟时间之和的线，此IO在正常状态为高电平，当发生Alarm时将电平拉低，并在释放FSP之后恢复为高电平。从图中可知，Alarm发生时ERR引脚停止高低电平切换并拉至低电平，但由于在恢复延迟时间内ERR引脚重新开始高低电平切换，故SS1和SS2引脚始终处于高电平。由于与图6相对应，故测试通过。

4　结论

本文为实现安全目标“避免VCU非预期的转矩输出异常”，基于TC275的三核架构与TLF35584的安全状态控制，设计了一种基于EGAS架构的转矩控制3层监控策略。首先，以相关项定义为基础，进行HARA分析，确定安全目标及其ASIL等级，进而导出功能安全要求与技术安全要求。其次，详细设计3层架构中的每一层，每层均分配一个CPU实现充分覆盖并尽可能解耦，此外设计了故障处理策略使系统在出现故障时能进入安全状态。最后，开展处理器在环测试：通过Level 1和Level 2的UDE调试测试表明所设计策略能对故障快速响应并进入分级限速状态；通过UDS诊断表明Alarm的有效性以及能读出SMU 的故障；通过TLF35584 安全状态控制测试表明TLF35584 能有效响应TC275 SMU 的Alarm并进行安全处理。综上所述，证明所设计的3层监控策略能实现所定义的安全目标。