一种基于AUTOSAR的电机控制器软件架构设计

0、引言近年来汽车的电气化电子化程度不断提高，控制器和软件功能数量急剧增加，硬件平台呈现多样化，导致软件复用性低，开发成本上升。为了解决这些问题，2003年由9家汽车行业的巨头携手合作，提出了致力于为汽车工业开发的一个开放的、标准化的软件架构，即汽车开放系统架构(AUTomotiveOpenSystemARchitecture，以下简称AUTOSAR)。汽车企业采用AUTOSAR标准架构定义控制软件已经是主要趋势。许多中国厂商也成为AUTOSAR联盟成员。目前，AUTOSAR标准普遍应用于汽车电控系统软件研发中，构建和设计符合AUTOSAR标准的软件架构，学者们已在汽车多个控制单元如柴油机后处理控制、主动安全带控制等展开研究。在电动汽车驱动电机领域，传统电机控制器的研究普遍以控制算法为核心，以电机运行状态及性能为目标，聚焦于电机本体-控制器的自闭环系统功能实现。而对于控制器与整车的通讯、数据以及功能安全的信息交互少有设计和研究，且控制器没有进行分层设计，软件与软件、软件与硬件耦合严重。随智能化控制趋势的逐步推进，电动汽车架构网络逐步发展成分层、模块化、少耦合特征，电机控制器作为整车电子控制单元之一，更应考虑在其自闭环系统之外匹配整车分层架构并适应系统特性，针对其与整车的通讯、信息交互和系统容错、功能安全的研究与电机控制算法的需求和重要性并驾齐驱。另一方面，电机控制器内部功能模块同样不断增多，软件越来越复杂，开发商也有多样选择，进行软件架构设计，减少其内部软硬件耦合、提升开发时间和成本效能愈发凸显意义[7]。国内一些公司正在开发基于分层设计的软件架构。各电机控制器开发单位已完全掌握电机控制策略、保护策略等上层软件及核心算法的开发，但是涉及底层硬件外设的配置与抽象等的底层软件开发目前还处于起步阶段。对于功能安全的考虑还在不断完善中。国内外对于AUTOSAR在电机控制器软件架构上的应用仍处于起步的探索阶段。对宏观架构设计而言，需进一步对分层设计的准则进行明确阐述，电机控制器架构与上端整车控制器、下端底层硬件的解耦目标有待明晰；从具体实现角度来说，需更好地提高对整体架构资源利用率，涵盖更多电机控制器的功能，尤其是对于构架的通用性和开发与整车性能密切相关的状态检测与故障诊断等安全功能模块的考虑还不够充分。为构建更通用的电动汽车电机控制器的软件架构，上层软件的可移植性、底层硬件与软件的高度解耦性、整体架构的高安全性是本文旨在追求的目标。本文将提出一种同时考虑电机运行控制和功能安全的AUTOSAR电机控制器软件架构，结合AUTOSAR的架构特点和电机控制器的功能特性，对分层思想和原则进行明晰，建立完整的构架体系，对各层进行功能和原理解释，并通过具体实例进行分析说明。1、AUTOSAR基本思想与构成AUTOSAR架构将运行在微控制器上的软件分为三层[15]：完全独立于硬件的应用层(ApplicationLayer,以下简称APP)和与硬件相关的基础软件层(BasicSoftware,以下简称BSW)，以及在两者之间设立的实时运行环境层(RuntimeEnvironment,以下简称RTE)，如图1所示。图1AUTOSAR标准架构图AUTOSARAPP主要包括三部分：应用SWC，接口与可运行实体。APP软件包含许多独立的软件组件单元，一般分为应用软件组件、传感器软件组件以及执行器软件组件三类。软件组件的内部行为通过一个或多个可运行实体实现，软件组件之间通过接口进行交互，完成数据传输和函数调用操作。运行时RTE是AUTOSAR中虚拟功能总线(VirtualFunctionBus,以下简称VFB)的具体实现，基本要求是实现和管理AUTOSAR的软件组件间、基础软件间、软件组件与基础软件之间的通信，以保证其通信行为正确，并且相互之间不会干扰，使组件设计可以专注于内部算法的实现和优化。同时，RTE作为APP和BSW的衔接，为APP提供标准接口来调用底层的资源，使得ECU软件的开发与具体的硬件相脱离，上层应用策略开发人员可以更加专注于软件功能的开发，而不用纠缠于软件底层的细节，增强系统的安全可靠性。BSW主要分为四部分：微控制单元(MicroControlUnit，以下简称MCU)抽象层、ECU抽象层、服务层以及复杂驱动层。BSW负责将底层控制器提供的数据等信息进行抽象传输至APP，实现软硬件的解耦，同时为APP提供一些基本服务。MCU抽象层位于BSW最底层，包含内部驱动，可以直接访问MCU及片内外设，可分为MCU驱动、存储器驱动、通信驱动和I/O驱动四部分，各部分由具体的与MCU硬件相对应的驱动模块组成。ECU抽象层负责提供统一的访问接口，实现对通信、内存或者I/O的访问，从而无需考虑这些资源是由MCU提供还是由外部设备提供，MCU外部设备的驱动就位于这一层，该层主要由板载设备抽象、存储器硬件抽象、通信硬件抽象和I/O硬件抽象四部分组成。服务层是BSW的最高层，可以实现与APP软件的关联，主要分成通信服务、内存服务、系统服务。通信服务通过通信硬件抽象来与通信驱动程序进行交互，为车辆通信网络和车载网络的诊断通信提供统一接口；内存服务负责非易失性数据的管理，以统一的方式为应用程序提供数据，同时对存储位置和属性进行抽象；系统服务包含一组模块和函数，如实时操作系统(定时器服务)、错误管理等，这些资源可以被所有应用层软件调用。复杂驱动层作为BSW中由用户自主开发的模块，主要针对AUTOSAR不支持或者未标准化的硬件资源，实现处理复杂传感器及执行器的特定功能和时间要求。该层可以通过提供AUTOSAR模块可配置的接口与分层架构的其他模块进行互相访问。2、电机控制器各部分功能描述及软硬件支持电机控制系统主要执行总线传输过来的整车转矩、转速和方向等控制命令，通过读取位置和电流电压传感器，获得电机的状态，经过算法计算出电机逆变器的PWM开关控制信号，通过控制电机的电流和电压实现电机的运行状态控制。同时，为了提高系统的安全可靠性，控制器需要通过传感器信息和网络数据监测电机系统的状态，进行故障诊断和容错以及保护等控制。软件主要具有数据获取、数据解算、控制算法、状态监测、数据存储以及通信服务等功能模块。具体功能描述如图2所示。图2电机控制器功能模块及其软硬件支持其中数据获取模块⑥是控制器的基础功能，并且与外部电机直接关联。其主要依托电压传感器、电流传感器、ADC采样电路、温度采样电路以及旋变解码电路等硬件电路的支持，获得电机的电压、电流、温度、转速以及位置等基础数据，为控制器的各部分功能提供原始的数据支撑。数据解算模块③与控制算法模块②是控制器的核心功能。其中数据解算主要是对获取的电机数据进行Clarke变换、Park变换等处理，为控制算法提供直接数据支持。而控制算法由来自整车控制器的指令进行选择，常见的控制策略包括涵盖矢量控制、直接转矩控制等的转速、转矩控制模式。根据不同的控制算法输出，再通过选择电流闭环、iPark变换、SVPWM等数据解算模块产生控制信号，并依托驱动电路的硬件支持，最终产生开关信号。状态检测模块⑤则包括自检、过流、过压、过温等保护以及基于大数据分析、数字孪生技术等工况识别、故障诊断与寿命预测等。通过对获取的原始电机状态参数的判断，确定是否发生过流过压过温等现象，若有上述现象发生，将产生相应的报警信号，并清除PWM软件使能，阻止SVPWM模块产生开关控制信号，终止上述现象对逆变电路及电机的损害。而工况识别及故障诊断与寿命预测则是利用电机运行的状态参数进行更深层次的计算对比分析，并输出相应的寿命预测值及故障特征量，同时根据识别的工况及时调整控制策略，以达到最优的燃油经济性[17]。数据存储模块④主要存储电机标定数表以及故障信息库数据。其中电机标定数表主要是为控制算法如最大转矩电流比(MTPA)控制提供数据，根据整车控制器下达不同的目标转矩反馈给控制算法相应的交直轴电流，达到电机控制器的MTPA控制。而故障信息库则是将状态监测中故障诊断模块反馈的故障特征信息及相关电机运行参数进行存储。通讯服务模块①则是通过CAN通信、485通信等通信方式与整车控制器以及其他控制器进行交互，将电机转速、转子温度、报警信号以及故障类型上传给整车控制器，同时接收整车控制器下达的目标转速、目标转矩以及控制模式选择等信号。综上，电机控制器通过通讯服务模块与整车控制端进行信息交互，依托硬件电路获取电机的运行状态参数，完成电机控制相关算法的具体实现，形成连接整车控制端与电机本体的统一整体。3、基于AUTOSAR的电机控制器软件架构设计构建符合AUTOSAR规范的软件架构，对于电机控制器层面，各算法功能应确保实时、准确实现，且应完成软件与硬件、软件与软件间的解耦；从整车架构层面，分层后的电机控制器软件应与整车具有良好的兼容和互操作性。基于以上原则，本文从以下三个角度提出新的分层架构：(1)对于整车开发者，用户控制端和电机控制器的信息交互应当仅限于APP软件，不同电机控制器厂商和整车架构的兼容在于顶层软件的反复适配，具体表现在二者间特定接口的一致性配置；(2)对于底层硬件，不论是MCU内部资源还是外扩电路，都应严格保证和上层软件的完全解耦；(3)对于高实时性和安全性的功能任务，标准化的AUTOSAR流程不足以满足需求时，需要对架构中的复杂驱动层进行特殊设计。本文基于AUTOSAR的电机控制器软件整体架构如图3所示。图3基于AUTOSAR的电机控制器软件架构图3.1控制器硬件层和基础软件层的各分层功能概述MCU及硬件层在电机控制器中是MCU和外接电路的总体呈现，主要包括MCU、ADC采样电路、温度采样电路、旋变解码电路、通信驱动电路、传感器以及功率电路等硬件。其中与转速、位置、温度等相关的硬件接口直接与电机连接，电机控制器与整车进行数据交互的部分通讯接口与整车控制器相连。BSW主要包括四个部分，呈现出自下而上的三层架构以及一个独立的复杂驱动层。MCU抽象层作为最底层，包含了PWM、ADC、旋变等I/O驱动，SPI、CAN/CANFD、FLEXRAY等通信驱动，FLASH、RAM、ROM等存储器驱动，以及定时器、Watchdog等MCU驱动，使系统软件与具体MCU型号无关。ECU抽象层为不同的总线通信以及不同的内存设备等分别提供统一的访问机制，使上层软件与硬件设计无关，不用考虑软件所需的硬件资源由MCU或者外扩电路提供，从而实现软件与硬件的完全解耦。服务层作为BSW内部的最高层，可以为APP软件提供标准化的基本服务，如存储器服务、通信服务、诊断服务等，具有一定的用户可配置性。存储器服务模块承担着基础软件服务层中的内存服务，其本质为非易失性存储器(Non-VolatileRandomAccessMemory,以下简称NVRAM)，与具体的ECU无关，具有高度可配置性，可以完成数据的修改、检查、校验、存储等功能，具有和APP软件通信交互的能力。在电机控制器中其主要存储电机标定数表与故障信息库。诊断服务主要用于故障读取、报告和错误记录。该过程主要由诊断事件管理器(DiagnosticEventManager,以下简称DEM)、诊断通信管理器(DiagnosticCommunicationManager,以下简称DCM)、函数禁止管理器(FunctionInhibitionModule,以下简称FIM)具体实现，DEM和APP的故障诊断算法进行交互，报告是否有故障发生；FIM根据报告的事件状态，使能或禁止APP软件组件内部的功能实体；DCM接收故障诊断请求，并可以完成对基础软件的调用或将信息传递至整车控制器进行故障处理。同时当诊断出故障以后DEM还可使用存储服务接口来实现故障信息储存，将NVRAM中积累的诊断信息库通过通信服务上传至整车控制器，能够结合大数据进行智能算法的开发等。复杂驱动层一般用于处理具有高实时性和复杂性要求的任务，可以使顶层软件直接与底层硬件进行交互，实现特殊功能。在电机运行过程中，过流过压保护需要具有快速实时的反应性，复杂驱动层能够对硬件检测电路的报警信号进行抽象，并通过逻辑判断迅速做出反应。此外，在电机控制中，转子位置的获取通常有较高的实时性要求且较为复杂，如增量编码器解算位置以及英飞凌Tricore系列的MCU具有的DSADC软解码位置外设，可以放在复杂驱动层实现进行电机位置的软解码。由于复杂驱动层直接连接着底层硬件，不可避免地会产生耦合致使该模块不具备可移植性，因此本文将该层内部划分为ECU驱动抽象层和算法实现层，如图4所示，前者可直接参与硬件的配置，不具有通用的可移植性，后者与具体的硬件资源无关，如逻辑判断算法、转子位置信号解算算法等。图4复杂驱动层内分层结构3.2APP软件分层设计前文提到，电机控制器功能模块逐渐趋于复杂化、多样化、智能化，AUTOSAR应用层的各软件组件虽以模块化进行划分，当其数量增多、实现的功能分布在多层面、多角度且较为繁杂时，软件间的交互和位置关系若不进行额外设计，可复用性以及系统效率将会降低。本文考虑对APP内各软件组件进行再分层设计，按照各个模块的功能特性、优先等级，将其划分为数据解算层、控制算法层、状态监测层及整车控制层，如图3所示。层与层之间仅涉及数据交换及指令调用接口，无其他耦合存在。数据解算层除了包括基本的传感器/执行器软件组件外，还用于实现Clarke、Park、iPark、SVPWM等计算算法软件组件，其共同特点有以下三点：(1)算法流程固定，具有完全的可移植性；(2)在电机矢量控制中，开关频率一致，方便系统进行统一映射处理；(3)在目前主流的多核架构下，可以有针对性地进行任务分配，如统一分配给数据计算核或异构多核架构中计算能力更强的主核，提高系统整体运行效率。控制算法层主要包括电机矢量控制和直接转矩控制等。以磁场定向控制(FOC)为例，选择MTPA或者转速模式不会对数据解算层中的算法流程或系统对其的任务调度安排产生影响，即数据解算与电机在何种控制策略下运行无关，两层之间只需定时进行数据交互而无其他耦合，故设计控制算法层仅需考虑控制策略的切换和选择。同时该层需留出与整车控制进行信息交互的接口，以获取用户对于工作模式的需求。状态监测层承担电机的故障诊断、过压/过流/过温保护等功能，电机各类故障诊断方式共性点在于对故障特征量进行提取和计算。结合上文对BSW诊断服务模块的分析，电机故障诊断流程可以按照图5形式进行。当APP的诊断算法检测到故障发生时，将通知DEM模块进行处理，DEM确认故障发生时调用NVRAMManager对信息进行储存，还可以依据存储器中已有的故障信息库进行核验，确认诊断结果的准确性。同时，存储的数据库可以批量向云端发送，为数字孪生、预测诊断等智能算法的实现提供架构支持；此外，DEM调用FIM触发软件保护，当故障发生时按需求及时禁止应用层软件控制算法实现停机；最后，故障信息通讯由DCM模块完成，当其接收故障诊断请求时，一方面可以向下层通信至MCU处触发硬件保护，如闭锁PWM等；另一方面可以通信至上位机，由用户对故障进行处理。过压/过流/过温保护则是将BSW传递上来的电压、电流与温度等数据与系统设计的安全阈值进行比较，当任意一项指标超出安全阈值时，该保护机制将清除SVPWM计算模块的使能信号，在APP切断开关信号的产生，同时向上层整车控制器报告相应的监测结果。图5电机故障诊断流程整车控制层用于完成电机控制器和整车开发控制端的信息交互，通过特定的接口设计，一方面获取整车端对控制算法层中电机工作状态、工作模式、旋转方向以及目标转矩与转速的设定要求；另一方面将状态监测层的电机运行状态、控制器运行状态以及重要状态参数反馈至用户界面，进行实时监控。该层在抽象意义上属于整体架构的最高层，在具体实现层面依托于通讯及相关驱动实现。4、实例分析与验证结合前面分析，本文选取了电机FOC算法以及电机过流保护、匝间短路故障诊断三个实例，以软件流程图和辅助程序代码的形式对分层架构下的系统运行流程进行说明，并通过TMS320F28377DDSP实现该AUTOSAR软件架构，利用如图6所示的实验平台对本文的架构思想和功能进行分析和验证。图6实验平台实物图4.1FOC算法FOC算法的软件流程图如图7所示。由图7可见，将查表寻数等行为在BSW中的存储器服务中配置完成，上层软件则只需要发出查表指令，当底层硬件进行更换时，只需更改与硬件交互的BSW中NVRAM中存储的标定关系脉谱图，而保证APP软件不受干扰，从而具有完整的可移植性，实现软件与硬件之间的完全解耦。其次，将数据解算和控制算法分别置于APP内的不同层次，数据解算层中的计算算法仅需按照开关频率周期性的进行执行，无需知晓当前电机处于何种控制策略之下，无需人工干预，它和控制算法层仅涉及数据的周期性交互，由图7中iPark变换程序实例可以看到，两层间的数据传输由特定的RTE接口函数进行管理，如图7中框选部分，该函数仅服务于读取特定电压信号而无其他作用。由此可实现APP软件内部的层与层间解耦以及数据解算层的打包任务调度和完全可移植性。而对于控制算法层，由于具体的控制策略需要上位机给定，故在该层留出一个与整车控制器交互的接口，用于指令信息的获取，同时对该接口进行明确定义管理，这样从整车开发的角度，当具体的电机控制器进行更换时，开发者只需重复进行新的电机控制器和已有整车接口的适配工作，无需对整体架构进行更改。图7FOC算法软件流程图对FOC控制的转速与转矩模式进行相关实验验证。图8为电机运行于FOC转速模式下，电机转速由200r/min变化为2000r/min的实验结果。图9为电机运行于FOC转矩模式下，电机运行转速为1000r/min，转矩由0变化为10N·m的实验结果。图8转速模式下的转速、电流波形图9转矩模式下的电流、转速波形在电机运行过程中，任取两个控制周期，可观察到电机在FOC模式下基于AUTOSAR架构的软件运行流程。图10分别为BSW及硬件层、APP数据解算、APP控制算法的运行状态图，标志位置“1”代表程序正在该层内执行，置“0”时表示该层处于静默状态。与图7的软件算法流程图相对应，实验结果与理论设计保持一致，体现出分层运行与层间解耦特点。图10FOC控制下软件架构分层运行状态图4.2电机过流保护电机过流保护的软件流程图如图11所示，电流电压经过电流电压传感器采集之后，同时进行ADC采样以及硬件过流检测。其中硬件过流检测电路判断电流是否处在所设计的安全范围内，当发生过流情况时，硬件检测电路将产生相应的电平报警信号。任意一相报警信号都将使PWM驱动的使能信号失效，阻止开关信号的产生。与此同时，电流采集信号经过ADC采样电路转化为数字量后，在过流保护程序中进行阈值判断，当发生过流情况时，产生相应的数字报警信号。该数字报警信号将使SVPWM模块的使能信号失效，直接在软件层级屏蔽开关控制信号。综上，当发生过流情况时，硬件层级保护能够快速直接切断开关信号，而软件保护则从源头上阻止开关控制信号的产生。软硬件结合的双重保护机制能够最大程度保护电机及控制器的安全。将硬件保护逻辑设置在复杂驱动层，使其能够直接与硬件电路进行交互，当过流情况发生时，能够实时快速地作用于I/O驱动，使PWM驱动使能失效，充分利用复杂驱动层的快速实时反应，最大程度减小过流对电机与控制器的影响。此外，当硬件电路发生改变时，开发者只需对接口数据范围进行适配，无需对整体架构进行更改。图11电机过流保护流程图4.3匝间短路故障诊断匝间短路故障诊断的原理如图12所示[19]，当电机在线运行时，通过提取α、β轴的反电动势，经过滤波、变换处理计算出故障特征量的大小，当其超出设定阈值时即发出故障信号。图12匝间短路故障诊断原理诊断的软件流程图如图13所示，其充分调用了BSW的模块化服务资源，和APP算法进行合理配合，将诊断分层次协调完成。电机起动运行后，电流、位置等信号在BSW完成标定转换后将上传至APP数据解算层，通过计算得到α、β轴的反电动势，将其传输至故障诊断层，进行匝间短路滤波、故障特征量的算法计算和执行。一旦发生故障，一方面该算法进行二次校核，另一方面将信息传递给BSW的DEM故障处理模块，在BSW中进行故障信息存储、触发软件和硬件保护以及将故障信息通过DCM通讯模块传至上位机进行人工处理。该流程中，APP数据解算同样只需按照设定的周期执行，并把结果传递至故障诊断算法层，该层次计算由BSW中上传的软件使能信号进行禁止。故障诊断层中，各诊断算法分别进行封装，需要进行某种故障判断时由上位机给予使能信号。如图13中的部分程序实例所示，该