标签: 整车控制器

背景介绍 为了保证汽车电子电气的可靠性设计，在 2011 年发布了 ISO 26262 （道路车辆功能安全标准）， ISO 26262 标准 横向视角来看，解决的问题是：减少汽车电子电气系统发生系统性失效的可能性，采用的方式是全生命周期全系统的安全管理方式，从而保证安全相关的电子产品的功能性失效不会造成安全事故。标准还提供了审核方法，使安全体系形成闭环。 由 Pi Innovo 设计和制造的 OpenECU M560 整车控制器 ECU 是针对特定的功能安全目标集而开发的，可以满足 ISO 26262 ASIL D 功能安全，适用于通用快速原型平台或小批量生产。 本文将介绍 M560 系列 OpenECU 硬件模块和软件平台的功能安全体系架构和设计特性，验证其是否可以达到 ISO 26262 ASIL D 安全等级。 北汇信息作为 Pi Innovo 的合作伙伴，将为您的 ISO 26262 功能安全需求提供相关产品和技术服务。我们期待与您密切合作，了解和完善您的功能安全要求 (FSR) ，选择适当的硬件，以满足您的项目需求。 M560 功能安全概要 之前的文章已介绍过快速原型 M560 系列 OpenECU 的硬件资源和应用范围，（点此回顾→ 符合ASIL-D 的纯电动/ 混动整车控制器M560 正式发布 ）提到了通过可选的硬件冗余以及在副处理器（ ST Micro SPC560P34L1CEFAR ）上校验软件的实施， M560 可以满足 ISO26262 ASIL D 功能安全需求。 作为符合 ASIL-D 安全目标的 ISO 26262 ： 2011 项目的一个要素，其功能安全通过以下提供的架构实现： · 具有非对称硬件冗余和多样化软件冗余的双处理器架构 · 两个处理器器判断来激活输出 · 输入路由到两个处理器进行交互计算 · 副处理器能够独立的激活 / 关闭 CAN 总线 M560 功能安全最大 ASIL 等级取决于具体的应用程序使用和应用程序软件实现的实际安全机制。表 1 总结了如果使用所有可用的内部安全机制下 M560 的 ASIL 最大等级；图 1 以图形方式描述了这些场景。 Table 1 - Maximum ASIL Figure 1 - ASIL scenarios 浅析 M560 功能安全实现架构 M560 主要是为纯电动 / 混动汽车设计的动力总成监控控制器，它包含一个主处理器，安全功能目的的副处理器，两个传感器电源， 4 个高速 CAN 总线，以及丰富的输入和输出 IO ，包括 SAE J1772 接口（电动车及插电式混合动力车传导式充电接口）。 系统操作环境要求 M560 仅在技术规范中规定的操作环境中使用时，才能实现指定的 ASIL 等级，并进一步局限于以下表 2 准则。 Table 2 - M560 qualified operating environment 功能安全实现示例 M560 提供下表 3 所示安全功能： Table 3 - M560 safety functions M560 对系统集成要求 （ ISO 26262 10-9.2.2 step 1b ） 在系统中使用 M560 必须符合表 4 中指定的要求： Table 4 - M560 system integration requirements 实现安全功能需求 M560 满足表 5 中规定的安全功能需求： Table 5 - M560 safety requirements OpenECU 软件开发 M560 平台软件是依据 ISO 26262 流程 ASIL B （ D ）等级以及结合具有 ASIL B （ D ）等级的软件来开发的，其平台软件包含： 固件（ Firmware ） · Bootloader · Reprogramming mode 操作系统（ Operating System ） · Primary microcontroller: Priority ceiling preemptive task scheduler with rate-monotonic application task prioritization, tasks as fast as 1ms period on primary · Secondary microcontroller: non-preemptive, strict rate monotonic task scheduler · Platform library and application initialization · Stack monitoring · Device driver hardware interface (hardware abstraction layer 平台库（ Platform library ） · APIs to access the device drivers · Utility functions 软件开发工具链程序（ Software development toolchain utilities ） · Binary image preparation (OpenECU executable format) · ASAP2 file generation OpenECU M560 平台软件通过多种方式在两个处理器之间提供软件的多样化冗余： · 每个处理器的源代码是独立的 · 每个处理器的二进制文件由不同的编译器和链接器工具链生成 对于具体 M560 中两个微控制器的软件环境、可用的安全机制以及每种机制支持的诊断覆盖率在表 6 中列出了部分供参考。 Table6 - Software environment 另外软件开发配置和工具需要按以下特定的要求来配置： 工具要求 要满足本文的假设，需要以下工具，且是下述指定需求的确切版本。这些工具的新版本目前还不具备资格，因此不宜用于正式的开发。 · Mathworks Primary microcontroller: Matlab, Simulink, Stateflow, Sateflow Coder, Matlab Coder: R2015b (32-or 64-bit) · Diab Primary microcontroller: WindRiver compiler: version 5.9.4.8 with patch TCDIAB-14743 · CodeWarrior Secondary microcontroller: CodeWarrior Development Studio for MPC55xx/MPC56xx Version 2.10 主副处理通信 M560 在主处理器和副处理器之间提供专用的 UART 通信总线，该总线特征如下： · 242k 波特率 · 延迟：从传输请求到总线的出现的第一个位延迟小于 1ms ，加上传输时间（字节 / 波特）为请求 / 响应通信设计的轮询机制 · 应用软件负责检测通信超时 · OpenECU 平台软件只在消息校验和与消息数据匹配时将接收到的消息传递给应用程序，校验和值本身没有传递给应用程序 潜在故障管理 应用软件负责启动检查和协调潜在故障检查，包括： · 应用程序软件必须实现一个检查功能，即两个处理器可以彼此互相重置。 · 副处理器应尝试启用 / 禁用每个 CAN 总线，并通过使用主处理器软件监视通信来验证总线状态的变化。 · 对于副处理器使能的每个输出，副处理器可以关闭输出，而主处理器使用监视器确认输出失效以验证关闭命令即可尝试激活输出。 应用程序开发流程指导 M560 提供了 ECU 硬件和平台软件，共同辅助开发符合复杂的功能安全要求的应用程序。 Pi Innovo 对 M560 基于 ISO 26262 流程的安全相关条目应用程序开发提供了许多设想，这部分内容客户可以针对自己的具体应用和设想在基于 M560 硬件和平台软件的基础上进行相关的学习，如有需要可以联系北汇信息做进一步交流。 总结 ISO 26262 功能安全要求 ECU 硬件、应用程序软件和平台软件均满足整体功能安全目标， Pi Innovo 是基于经过验证的 V 模型来开发硬件和软件平台的，主处理器和副处理器上的应用程序软件由最终用户负责。任何一种软件都不能单独实现功能安全。因此，应用程序软件和平台软件必须依据 ISO 26262 流程的相同 ASIL 等级开发，才可以确保功能安全可实现。总而言之，安全是一个系统级工程，小到需要每个 IO 、 ECU 、软件，大到整车厂、供应商、汽车电子电气解决方案的通力协作才可能实现系统功能安全目标。 关于 Pi Innovo Pi Innovo 公司（成立于 1990 年）总部位于美国密歇根州，在发动机控制、新能源整车控制、底盘控制等领域具有多年的成功应用经验。其开发的快速原型系列产品 OpenECU ，基于 Matlab/Simulink 的开发环境、高效的自动代码生成、支持通用的标定工具，针对发动机、后处理、车辆稳定系统和新能源车辆控制系统开发提供有效的解决方案，适用于生产、试生产及大批量生产。 北汇信息作为 Pi Innovo 在中国的合作伙伴，将为客户提供全方位的支持和高效的控制策略解决方案。 参考文献 M560 Technical Specification (01T-070018TK-xx) ISO 26262 First edition 2011-11-15 29T-070064-01_M560 Family Functional Safety Manual SAE Webinar Pi Innovo M560-26262_Lessons_Learned_Webinar_06-FINAL 180524

前期如果想要从细节里面去描述整车控制器的话，就需要从新能源的电动驱动系统去理解。对于以下图来说，整车控制器就是汽车方面的大脑。 而对于大脑来说包含哪些方面的功能？上电流程管理，断电流程管理，汽车驱动控制，制动能量回馈控制，充电管理等功能。 上电流程管理：根据司机的操作，检查DC/DC几点起，低压几点起，高雅断路器，预充电继电器等是否存在故障，完成低压附件以及电机上电，保证安全。 断电流程管理：司机拔掉钥匙开关后，依次给低压附件，电机等部件断电，同时保存故障信息。 汽车驱动控制：根据司机的驾驶需求，车辆运行状态，道路及环境状况，经过程序计算，向电机控制器发出指令，满足驾驶工况要求。 制动能量回馈控制：根据制动踏板和加速踏板的开度m，车辆行驶状态，蓄电池状态，计算制动力矩并发送给电机。 充电管理：监控电池状态，进行充电保护。 故障诊断及保护：连续监控整车电控系统，进行诊断，并及时启动相应的安全保护处理。故障码的存储及回调，通过故障指示灯指出故障类别和部分故障码。 而对于以上面的功能来说还是比较的笼统的，接下来就来看看相对应的硬件平台。 对于图中左测的是输入信号，而右测的信号是输出信号用来驱动相对应的负载。对于整车控制器来说前期对输入信号进行相应的处理，如开关信号的隔离，踏板信号的整波等，在将处理后的相关信号输入给整车控制器MCU，整车控制器MCU将根据相应的控制程序对输入的信号，数据等进行分析，判断和计算，最终得出正确控制指令，并通过通讯接口及时的将控制指令发送给电机控制器，电机控制器将根据相应的控制指令来控制电机。当然了这里面也可以通RS232与上位机连接，只不过这个地方没能画出来，对整车控制器通讯进行监控。

“三电技术”（电机，电池及电控技术）是电动汽车的关键技术，整车控制器作为电控系统的核心，其开发遵循汽车电子的标准V-Cycle流程。而对于里面的硬件在环测试就是其中的一环，接下来针对于里面的HIL做一整方面的介绍。 对于目前上市面上在环仿真的工具有一下公司的产品：dSPACE公司的Simulator，ETAS公司的Labcar，MathWorks的xPC Targert以及NI公司的各类板卡，等等。对于产品的开发需要相对应的生命周期，然而对于HIL来说也拥有相对应的生命周期。 需求分析：主控制器的需求与功能定义，来分析HIL测试系统需要提供的测试功能。比如；输入输出接口的电器特性等。 HIL系统需要输出的信号，采集的信号以及信号的精度要求。 HIL系统的实时性，处理器主频太低或者模型太过复杂将会影响实时性。 HIL系统的硬件的可靠性与安全保护。 模型的详细程度，影响工作量。 管理的功能与涉及，实验数据的存储管理。 系统构建：需求与功能定义来搭建HIL的软件硬件测试环境。 硬件系统，软件接口，实验软件，对象模型。 确认测试：为了测试，确认HIL系统自身的可靠性，对模型进行的测试与校准。 功能裁剪：不同阶段的测试配置环境不同，针对于情况进行各个阶段的测试需求裁剪。 使用维护：根据HIL系统的软硬件测试环境，流程规范，测试操作进行测试，保证测试系统不被损坏。 对于以上搭建好的平台，也是需要验证各模块之间的联系。 以上是针对于HIL的流程方面做了一个梳理的工作，然而接下来的过程这对于具体的整车控制器这块作为例子来说明这个过程是怎样的体现的。

整车控制器 首先自己在研究新能源汽车这块的时候，发现里面的电控系统比较重要的是当中关于整车控制器方面的情况，所以针对于这块的知识点，做着属于接下来一些方面的总结事项。 作为硬件开发的人员，理应做到的是如何从硬件的角度来描述这个过程所涉及的知识点，以及在接下来的过程里面整车里面所要涉及哪些方面的事项来做到的是规避里面所出现的问题点。 当在这个过程对应的实物情况来说明的话，如下是负载相对应的信号汇总 。   整车控制器通过采集方向盘转角信号、加速踏板位置信号、制动踏板位置信号以及档位开关信号来判断驾驶员的驾驶意图，通过采集每个轮毂电机转子位置信号计算各个车轮的转速，然后估算出车速，判断当前车辆的行驶状态。综合所有的信息，整车控制器通过分析计算，判断车辆的行驶工况，并根据不同工况下的控制策略控制车辆的行驶。整车控制器通过RS485总线向4个轮毂电机控制器发送控制指令，控制电机动作，并通过控制继电器的开合来控制轮毂电机的上电和断电。 如果要从安全的角度来做好里面的细节的话，应该要从哪些方面着手去做哪些准备来实现这个过程的转变，那么接下来的过程所要做到的是在此过程之中 ISO26262 里面硬件方面的安全方面流程是怎样的一个模式是需要关注的。 在硬件层级层面来讲的话，由上诉所描述的硬件方面的模块方面应该如何去分解在这个过程所出现的安全等级方面的研究。 为了验证整车控制器 VCU 能否准确且有效地接收加速踏板和制动踏板的真实信号，能够控制电机输出正确的需求扭矩。该文通过模拟车辆在加速、起步和制动时的状态，判断整车控制 VCU 的性能，从而确定整车控制器 VCU 是否到达设计的目标。 起步测试： 测试开始时点火开关处于 Start 状态，在时间为 9 s 时踩下制动踏板，使制动踏板的开度达到 100% ，将整车的档位达到前进挡 D 档，松开制动踏板后，若此时未踩下加速踏板，则车辆进入蠕行状态（即车辆未踩下油门以某一低速行驶），从图 4 中可以看出，在 14 s 松开制动踏板的同时，电机的输出扭矩在逐步增大，整车的速度也随之增高，当车速达到 4 km/h 时，电机最大的输出扭矩为 35 Nm, 随着车速超过 4 km/h 时，电机的输出扭矩在逐渐减小，最后车辆以一定的速度匀速行驶，电机的稳定输出扭矩约为 6 Nm ，与设计要求符合。 加速测试： 加速测试主要是验证整车的动力性能，能够很好地控制电机的输出扭矩，在 32 s 时制动踏板，使制动踏板的开度达到 100% ，此时电机的输出扭矩迅速增加，并且达到最大输出扭矩后又下降进入恒功率区，在 50 s 时，使加速踏板松开，车辆进入滑行状态，电机在此时输出很小的负扭矩，整车的速度在逐渐减小。根据整车加速测试的结果分析得出整车控制器 VCU 满足加速设计的要求。 制动测试： 在 88 s ，踩下制动踏板使制动踏板开度达到 100% ，电机输出较大的负扭矩，整车进入制动能量的回收，随着整车速度的减小，电机的输出扭矩也在减小，当整车的速度下降为 0 时，电机的输出扭矩也变 0 。当整车的速度下降为 0 时，使制动踏板松开，车辆进入蠕行模式。根据整车制动测试的结果分析得出整车控制器 VCU 满足加速设计的要求。 而对于里面整车控制器的流程来说，如以下的整体模型与整体方面的思考 ; 然而对于整车控制器来说需要实现哪些功能以及这个功能对于在设计之中软件又是如何去实现都是在如下的描述之中得以体现； 整车控制器是纯电动汽车驱动控制的核心部件，本文设计的纯电动汽车的整车控制器主要实现纯电动汽车的基本行驶控制功能。因此，应具备以下功能：   整车控制器主要实现纯电动汽车的基本行驶控制功能。整车控制器控制纯电动汽车的基本行驶控制功能主要包括：起步控制、加速控制、减速控制、转向差速控制、制动控制、前进与后退档位控制等。如何实现这个方面的流程当面的图示 本文在整车控制器的软件设计中采用分工况控制的方法。因此，在主控制程序中必须进行相应的工况判断。工况判断需要的参考量有车速、加速踏板开度、制动踏板开度、方向盘转角和档位信号等。本文第三章已经对纯电动汽车的行驶工况进行了详细的分析，并且制定了相应的控制策略。工况判断应该根据驾驶员的操作顺序，逐一对采集到的信号进行判断，与工况条件进行对比，满足工况条件则按该工况执行相应的控制程序，若不满足，则重新判断。因此，在工况判断 程序中，必须考虑到车辆行驶的所有工况，并且必须明确每个工况的判定条件，如此，驾驶员的操作才能被执行，否则，工况之间不明确，程序可能会无法执行或进入死循环。这部分程序必须进行细致的设计，考虑到每一种情况，不能有遗 漏。在这部分的程序设计中，本文根据驾驶员的驾驶习惯逐一对采集到的信号进行判定。工况判断程序流程如图5．3所示。首先判断制动踏板信号，在所有信号中，制动踏板信号应该是优先级最高的信号，由于本文设计的制动系统仅为机械制动，没有电机的制动能量回馈，为了驾驶安全，在任何情况下，一旦采集到有效的制动踏板信号，整车控制器应该发出控制指令，使轮毂电机断电。之后判断档位信号，当档位为空档时，程序将不执行数据发送程序，并且控制主继电器断电，电机处于无动力状态；档位为倒档时，为了使纯电动汽车的驾驶感觉和传统汽车类似，要进行速度限制。接下来就可以根据车速和加速踏板信号，判断车辆是起步工况、匀速工况、加速工况还是减速工况等。另外，根据方向盘转角信号处理程序的结果判断，若转角信号为零，则进行直线行驶，数据发送子程序将给四个电机控制器发送相同的数据，控制四个电机产生相同的转速；若转角不为O，则将调差速计算程序，计算每一个车轮的速度，然后转换为相应的控制指令，发送给电机控制器，使车辆进行差速行驶。 接下来的过程之中所要做到的是在这个过程把以上的文件整理成相对应按下面的例子来做到此流程的转换； 基本上上面的资料都已经满足这方面的内容。 后续的过程之中能够做到的是在总结的过程能够做到相对应的针对于不同的课题能够实现在这个过程当中所形成的思路与脉络，同时能够在知识梳理的过程出现的点滴也能够彼此之间找到不同的地方，不仅如此而且也能够实现在所有知识点的转变为自己脑海之中对于所有的生活与工作之中的转变，也不负自己在这个过程之中所能够实现的一切知识点，也能够让自己知道在彼此知识点的梳理过程转变成自己所认可的知识点。