标签: ecu

来源：虹科汽车智能互联 虹科方案丨低负载ECU老化检测解决方案：CANCAN FD总线“一拖n” 原文链接：https://mp.weixin.qq.com/s/4tmhyE5hxeLFCiaeoRhlSg 欢迎关注虹科，为您提供最新资讯！ #汽车总线 #ECU #CAN卡 导读 在汽车电子行业中，ECU（电子控制单元）是控制车辆各种系统的关键组件，如发动机控制单元、制动系统、空调系统等。ECU负责监测和管理车辆的各种功能，它们通过接收传感器数据并对其进行分析来确保车辆安全、性能和效率。ECU的老化可能导致诸如性能下降、功能失效甚至安全风险等问题，因此对ECU老化进行检测非常重要。本篇文章为您介绍虹科低负载ECU老化检测解决方案。 ECU老化检测的必要性 ECU的老化可能导致诸如 性能下降、功能失效甚至安全风险等问题 ，因此对ECU老化进行检测非常重要。这有助于保障车辆运行的稳定性和安全性，同时提升车辆的使用寿命和效率。 安全问题 ECU老化可能导致系统故障，影响制动、转向等关键功能，可能增加事故风险。通过定期检测ECU老化，可以及早发现潜在的问题并进行修复，提高车辆的安全性。 性能下降 老化的ECU可能导致性能下降，例如引擎效率降低、燃油经济性恶化等。定期检测可帮助及时识别并解决这些问题，提高车辆性能和效率。 系统不稳定 ECU老化可能导致系统不稳定或意外的故障，例如电气系统中断或电子元件失效。通过定期检测老化状况，可以预防这些问题并维持系统的稳定性。 影响使用寿命 及时检测和修复ECU老化问题有助于延长车辆整体的使用寿命，避免更严重的损坏并减少维修成本。 因此，对ECU老化进行定期的检测和维护对于确保车辆安全、性能和可靠性至关重要。这有助于保障车辆运行的稳定性和安全性，同时提升车辆的使用寿命和效率。 行业痛点 接入CAN卡发送检测指令报文，由于总线节点过多，负载过高，无法正常通信 以车灯为例，在现代汽车工业中，安全一直是首要任务之一，而车辆照明系统在夜间行驶和恶劣天气条件下起着至关重要的作用，因此车灯的性能至关重要。然而，随着时间的推移， 车灯可能会因老化而性能下降，这可能对驾驶安全构成威胁 。为了解决这一问题，越来越多的汽车制造商采用了CAN/CAN FD总线技术来进行车灯老化检测，以确保车辆的照明系统始终处于最佳状态。 一种经典的车灯老化检测方法是模拟CAN/CAN FD节点，发送特定的指令报文，根据ECU的报文反馈来判断车灯的老化程度。但在实际操作中，由于CAN/CAN FD总线的带宽有限，一条检测总线上只能同时检测6-7个车灯ECU， 想要同时对数十个甚至上百个ECU进行检测，往往会有总线负载的问题 。 鉴于此，为了有效降低总线负载对车灯ECU检测的影响， 虹科推出6通道的PCAN-Router Pro FD网关 ，致力于实现多节点通信，解决总线高负载通信的问题。 低负载ECU老化检测方案 通过6个通道将新的CAN FD和经典CAN总线的数据流量连接起来。可插拔的CAN收发模块允许灵活地适应每个CAN通道的不同需求，适用于对测试台和生产工厂的数据流进行管理、监视和控制。 PCAN-Router Pro FD级联操作，扩展更多的CAN/CAN FD通道 通过虹科低负载ECU老化检测解决方案，总线负载约降低至原来的1/6，检测效率提升至原来的6倍，且检测全流程只需控制一个CAN控制器。 结语 在汽车工业中，ECU的老化检测对于保障车辆的安全、性能和可靠性至关重要。然而，传统的检测方法往往面临着总线负载过高的问题，这限制了检测的效率和范围。虹科方案通过创新的PCAN-Router Pro FD网关，成功地解决了这一问题。虹科PCAN-Router Pro FD网关的推出，为汽车制造商提供了一种高效、可靠的ECU老化检测解决方案。这一解决方案不仅提高了检测的准确性和效率，还为汽车工业的发展带来了巨大的价值。

来源：虹科汽车智能互联 虹科方案 | 释放总线潜力：汽车总线离线模拟解决方案 原文链接：https://mp.weixin.qq.com/s/KGv2ZOuQMLIXlOiivvY6aQ 欢迎关注虹科，为您提供最新资讯！ #汽车总线 #ECU #汽车网关 导读 传统的ECU模拟工具通常需要依赖上位机软件来发起通信，这在离线场景和自动化产线中带来不便。为了应对这一挑战，虹科推出了创新的汽车总线离线模拟解决方案，基于PCAN-Router系列网关，通过内部可编程固件，实现了自主报文自发功能和实时离线通信，为工程师提供了一个高效、灵活且安全的测试平台。 行业痛点 ECU模拟工具是专为模拟车辆电子控制单元（ECU）之间的通信和行为而设计的软件/硬件设备。它们具备 通信模拟、数据生成与处理、实时模拟能力、故障模拟功能 ，同时具有接口兼容性、调试分析功能和灵活的配置选项。这些工具在汽车电子系统开发、测试和验证中发挥关键作用，帮助工程师验证系统的正确性、稳定性，并加速新功能的开发和集成过程。 常见的ECU模拟工具，会根据不同的总线协议制作搭配上位机使用的“CAN卡”和“LIN卡”。就CAN/CAN FD总线而言， 一般的“CAN卡”都需要上位机发起，并通过软件/接口的形式进行报文的封装并发送，在部分自动化产线、离线场景中很不方便 。 ECU离线模拟的必要性 CAN/CAN FD总线ECU离线模拟工具的离线特性极为关键，允许工程师在不依赖于实际车辆的情况下模拟、分析和验证电子控制单元（ECU）之间的通信。 一方面，这种独立于实际车辆的离线模拟能力为系统开发、故障诊断和性能评估提供了非常重要的环境。不仅节约了在实际车辆上进行测试的成本和时间，更为工程团队提供了一个安全、可控且高效的平台，用于早期发现问题、验证新功能，同时优化系统性能。通过离线模拟，工程师能够更加灵活地、更频繁地进行测试和调试，从而提高系统的稳定性、安全性和可靠性，同时降低整个开发周期所带来的风险。 另一方面，任何一款新的ECU在加入已有的总线之前，都应该通过ECU离线模拟工具进行验证，确保ECU在量产前的通信情况与现有的总线架构是契合的。 汽车总线离线模拟解决方案 虹科基于PCAN-Router两个系列网关，推出了汽车总线离线仿真解决方案。 CAN总线方面：基于PCAN-Router系列网关，通过内部的可编程固件，自行的定义CAN/CAN FD总线报文结构，包括帧ID、DLC、TYPE、DATA等，并通过网关的CAN收发器自动的向总线上发送报文信号，建立实时的离线通信。 ECU模拟：内部的可编程固件基于C语言，可以自由的设定通信过程中报文的反馈效果，以达到ECU模拟的目的。 自主通信能力 与传统的ECU模拟方案不同，通过修改PCAN-Router FD的内部固件，实现了一种 自主报文自发 的功能。这意味着该模拟方法不再需要依赖上位机软件的手动控制来触发或模拟CAN/CAN FD总线上的通信报文。 无需人工干预的自动化模拟 能够 自动模拟 ECU在CAN/CAN FD总线上的通信行为，无需人工干预。通过修改PCAN-Router FD的内部固件，使其具备智能化的功能，能够根据预设条件或特定触发事件自发生成和响应通信报文。 实时、高效的CAN/CANFD总线仿真 提供了一种实时、高效的CAN/CAN FD总线仿真方法。该方法通过内部固件的优化，能够实现对CAN/CAN FD总线上的通信报文更快速、更精确的仿真，进而模拟ECU的实际行为，包括 数据传输速率和数据长度的灵活处理 。 PCAN-Router FD的固件改进 通过 针对性的固件修改 ，使得设备能够在不需要外部控制的情况下，模拟并响应CAN/CAN FD总线上的通信，从而提升了模拟ECU的效率和准确性。 增强CAN/CAN FD协议的兼容性与灵活性 不仅能够与传统的CAN协议兼容，还能支持CAN FD协议，提供了更高的灵活性。这种改进使得模拟ECU能够适应各种不同的通信需求和协议变化，从而更好地满足现代车辆和工业系统的通信要求。 结语 随着汽车电子系统的日益复杂化，离线仿真工具在汽车电子系统开发、测试和验证中的重要性愈发凸显。虹科方案推出的基于PCAN-Router两个系列网关的汽车总线离线仿真解决方案为工程师提供了一个高效、灵活且安全的测试平台。通过内部可编程固件自定义报文结构和反馈效果，该方案实现了自主报文自发功能和实时离线通信，满足了工程师对ECU模拟的需求。这种创新的离线仿真方法不仅提高了开发效率、降低了成本和风险，而且增强了系统的稳定性和安全性。在未来，随着汽车电子技术的不断进步和应用需求的多样化，离线仿真工具将继续发挥关键作用，助力工程师更好地应对挑战并推动汽车行业的持续发展。

智能汽车应用生态的需求高速成长 近年来全球车用半导体芯片市场大幅快速成长，根据摩根士丹利(Morgan Stanley) 2023年所发布的 最新报告 中指出，未来五年内的汽车高效能运算 Automotive HPC （High-Performance Computing） 半导体市场将会整整成长三倍，整体潜在市场估计将于2023年达到20亿美元，并且在2027年增长至60亿美元，年复合增长率(CAGR)为可观的29%。与此同时，受惠于汽车高效能运算芯片客制化设计需求的增加，芯片设计服务厂的预估累积收益可望在未来五年内提升多达20亿美元。 ［应用技术考虑］高速实时运算、数据沟通与传输 在新的连网汽车发展趋势下，高速数据通讯与 Automotive HPC 高性能运算平台需针对车辆内部各个电子控制单元ECU（Electronic Control Unit）进行整合管理与运算处理；因应不同ECU数据流量与低延迟需求， Automotive HPC 也需要搭配符合PCIe标准与AEC-Q100认证的PCIe封包切换器，藉此实现与各端点之间的高速整合、沟通与传输。 以「高频毫米波雷达应用」为例，各雷达感测数据将经由ECU再集中到 Automotive HPC 的实时图像处理单元。因此这类高流量实时图像处理需要搭配高速、低延迟、高可靠度且同步实时性良好的传输接口，例如传输速度可达10Gbps的Automotive Ethernet MultiGBASE-T1： 与PC主板概念类似； Automotive HPC 是透过PCIe信道搭配CPU、内存、I/O接口进行平台式的架构整合，如此才能整合控制车内各个ECU的沟通与运算。 各种不同类型的高速实时运算与应用： ✔ 传感器环境信息实时判读 ✔ 智能座舱／用户体验相关数据运算 ✔ 车辆控制／云端、物联网服务相关沟通与运算 ✔ 自驾功能的实时高速运算 ✔ 车辆安全与传感运动之高速运算／集中处理 从上述介绍中我们不难发现，Automotive HPC在 高频高效能运算电子组件 、 高速传输接口 以及复杂运算处理、资源分配的特性，再 搭配上各种 车辆的复杂应用情境条件 ，都再再证明了Automotive HPC对整个平台的讯号传输实时处理、系统稳定度、耐久度、兼容性与安全性的要求上有多严苛。 图片：在瞬息万变的行车过程中，任何HPC的潜在问题都有可能影响车辆操控、导致重大车祸发生，不可不慎。 智能汽车应用生态的潜在风险与危机，及开发上的挑战 开发者对 Automotive HPC 应用生态的熟悉度，可能力有未逮 大多数车厂或Tier1开发者缺乏PC领域/组件的相关开发经验及专业，对于Automotive HPC这种高度整合、高效能的平台方案不见得熟悉。 例如2021年Tesla就曾因闪存使用耐久度/寿命问题导致召回事件。 而造成此问题的原因便是车厂开发人员对 PC 相关组件规格与设计方案不够熟悉： 图片出处： eeNews Europe 开发者对 Automotive HPC 用户情境的事前评估与规划，可能有所不足 举例来说，在实际的应用情境 (User Scenario)条件下，当车辆环境温度变化较大，HPC组件就容易遭遇到高温条件的考验。CPU过热而运行缓慢或重新启动的状况下，就可能导致车机中控屏幕无法显示后视摄影机影像、换文件选择、挡风玻璃能见度控制设定以及警示灯，进而增加事故风险。 Tesla在2022年就曾因CPU过热问题导致召回事件。 此问题肇因于「高温条件」用户情境仿真并未在开发阶段被考虑： 图片出处： Electrek 隐藏在其它应用情境（ User Scenario ）背后的潜在危机 无线讯号质量差或延迟， 导致车主无法实时接收路况信息 传输错误率过高或噪声影响， 导致车辆功能错误、无法正常运作 智能座舱功能错误或反馈过慢需反复操作， 导致驾驶难以专注路况 高温环境、震动或耐久度差， 导致车辆系统容易发生故障现象 资安问题或黑客入侵， 导致车辆运作失能，恐酿车祸危害人身安全 智能座舱与用户手机、接口设备兼容性问题， 导致相关功能无法正常运作 这些应用风险可能来自于开发阶段的一些常见问题： 开发阶段 Automotive HPC 搭配高频传输接口时的常见问题 阻抗不匹配 时间延迟 噪声过多 衰减过大 误码率过高 讯号强度不足/异常 格式不正确 而之所以会导致这些问题发生，主要可能是开发人员遇到了一些难以跨越的挑战与瓶颈： 大多数车厂或 Tier1 开发者可能会遭遇到的技术门槛 缺乏高速高频测试经验 仪器设备的资源有限 验证环境的不易架设 新技术的导入能力有限 测试规格标准未能实时更新 用户情境仿真或测试手法的设计难度较高 欠缺专业验证人员的顾问咨询，以及测试验证的实务经验

什么是域控制器？ 过去十多年的汽车智能化和信息化发展产生了一个显著结果就是 ECU 芯片使用量越来越多。从传统的引擎控制系统、安全气囊、防抱死系统、电动助力转向、车身电子稳定系统；再到智能仪表、娱乐影音系统、辅助驾驶系统；还有电动汽车上的电驱控制、电池管理系统、车载充电系统，以及蓬勃发展的车载网关、 T-BOX 和自动驾驶系统等等。 传统的汽车电子电气架构都是分布式的（如下图 2-1 ），汽车里的各个 ECU 都是通过 CAN 和 LIN 总线连接在一起，现代汽车里的 ECU 总数已经迅速增加到了几十个甚至上百个之多，整个系统复杂度越来越大，几近上限。在今天软件定义汽车和汽车智能化、网联化的发展趋势下，这种基于 ECU 的分布式 EEA 也日益暴露诸多问题和挑战。 图 2-1 汽车分布式 EEA 为了解决分布式 EEA 的这些问题，人们开始逐渐把很多功能相似、分离的 ECU 功能集成整合到一个比 ECU 性能更强的处理器硬件平台上，这就是汽车“域控制器（ Domain Control Unit ， DCU ）”。域控制器的出现是汽车 EE 架构从 ECU 分布式 EE 架构演进到域集中式 EE 架构（如图 2-2 所示）的一个重要标志。 域控制器是汽车每一个功能域的核心，它主要由域主控处理器、操作系统和应用软件及算法等三部分组成。平台化、高集成度、高性能和良好的兼容性是域控制器的主要核心设计思想。依托高性能的域主控处理器、丰富的硬件接口资源以及强大的软件功能特性，域控制器能将原本需要很多颗 ECU 实现的核心功能集成到进来，极大提高系统功能集成度，再加上数据交互的标准化接口，因此能极大降低这部分的开发和制造成本。 对于功能域的具体划分，各汽车主机厂家会根据自身的设计理念差异而划分成几个不同的域。比如 BOSCH 划分为 5 个域：动力域（ Power Train ）、底盘域（ Chassis ）、车身域（ Body/Comfort ）、座舱域（ Cockpit/Infotainment ）、自动驾驶域（ ADAS ）。这也就是最经典的五域集中式 EEA ，如下图 2-2 所示。也有的厂家则在五域集中式架构基础上进一步融合，把原本的动力域、底盘域和车身域融合为整车控制域，从而形成了三域集中式 EEA ，也即：车控域控制器（ VDC ， Vehicle Domain Controller ）、智能驾驶域控制器（ ADC ， ADAS\AD Domain Controller ）、智能座舱域控制器（ CDC ， Cockpit Domain Controller ）。大众的 MEB 平台以及华为的 CC 架构都属于这种三域集中式 EEA 。 图 2-2 域集中式 EE 架构 域控制器市场概述 2018 年，基于德尔福提供的域控制器技术，奥地利 TTTech 公司开发的 zFAS 控制器率先应用在奥迪 A8 当中。伟世通公司则推出了 SmartCore 域控制器，集成信息娱乐、仪表板、信息显示、 HUD 、 ADAS 等功能。这些产品开创了商用功能域控制器产品之先河，全球各大 Tier 1 供应商纷纷跟进，整个域控制器市场逐渐发展起来。 在国内市场，华为、德赛西威、航盛电子、东软等企业也推出了 DCU 解决方案，并得到了国内车企的采用。比如， 2020 年小鹏汽车推出的智能轿跑 P7 就采用了德赛西威基于英伟达 Xavier 打造的自动驾驶域控制器产品—— IPU03 。 当前，整个业界对 DCU 市场都有非常乐观的预期。据佐思产研的预测， 2025 年全球汽车 DCU （座舱 + 自动驾驶）出货量将超过 1400 万套， 2019-2025 期间年平均增长高达 50.7% 。 图 2-3 全球域控制器市场预测 整个汽车行业普遍认为，域控制器是汽车电子行业未来竞争门槛最高的部分，因此利润也最高，芯片厂商和核心算法供应商将会受益。 ( 一 ) 域控制器市场快速增长背后的驱动因素 更多更好的 ADAS 功能和智能座舱与信息娱乐功能一直是推动域控制器市场快速增长的主要因素，这些新功能能明显提高整车的科技感和用户体验，因此也是主机厂开发新车型时的投入重点。 L1 到 L2+ 级别之间的 ADAS 应用是这几年发展非常快，很多功能都正在快速普及，比如：停车辅助、车道偏离预警、自适应巡航、碰撞避免、盲点侦测、驾驶员疲劳探测等。 域控制器需要一颗性能更强、集成度越高的主控处理器来作为其大脑，更多原本通过分离 ECU 实现的功能现在可以放到域主控处理器上来实现，也因此就能更加节省功能域里所需的 ECU 用量和其它硬件资源。更高的集成度可以更主机厂供应链管理实现 ADAS 域控和相关零部件平台化和标准化的要求。 ( 二 ) 对域控制器供应链的影响 汽车 E/E 架构的演进和发展，也深刻影响了主机厂和汽车电子供应商的供应关系。主机厂的核心竞争力从以前的机械制造为主，全面转向软件和算法为重点。预计未来整车厂与 Tier 1 供应商之间将可能有两种合作模式： 其一， Tier 1 负责域控制器硬件设计和生产，以及中间层 Middleware 软件部分。整车厂负责自动驾驶软件部分。 Tier 1 的优势在于以合理的成本将产品生产出来并且加速产品落地，因此整车厂和 Tier 1 进行合作生产方式是必然，前者负责自动驾驶软件部分，后者负责硬件生产、中间层以及芯片方案整合。这种模式下，在项目立项时，整车厂又可能跨过 Tier 1 直接与芯片厂商确定方案的芯片选型。 其二， Tier 1 自己与芯片商合作，做方案整合后研发中央域控制器并向整车厂销售，例如大陆 ADCU 、采埃孚 ProAI 、麦格纳 MAX4 等。 2.1 智能座舱域控制器 座舱智能化的实质是基于汽车驾驶舱中的人机交互场景，将驾驶信息与娱乐信息两个模块进行集成，为用户提供高效的、直观的、充满未来科技感的驾驶体验。智能座舱的设计诉求主要是用于提升用户的驾乘体验，同时还要保证用户驾乘的安全性和舒适性，最终实现汽车作为人们工作和家庭场景以外的第三生活空间这一终极目标。 智能座舱域包括 HUD 、仪表盘（ Cockpit ）和车载娱乐信息系统（ In-Vehicle Infotainment ，简称 IVI ）三个最主要的组成部分。 HUD 是非常实用的功能，将 ADAS 和部分导航功能投射到挡风玻璃上，诸如 ACC 、行人识别、 LDW 、路线提示、路口转弯提示、变道提示、剩余电量、可行驶里程等。 HUD 将很快会演变为 AR HUD ，在 L3 和 L4 时代成为标配。 进入 L3 时代，驾驶员状态监测（ Driver Status Monitor ， DMS ）将成为必备的功能，包括：面部识别、眼球追踪、眨眼次数跟踪等将引入机器视觉和深度学习算法。而 L4 时代则必备 V2X （ Vehicle to everything ）。 另外，多模态交互技术的蓬勃发展将会极大改变用户与汽车的交互模式。基于语音识别功能的语音交互技术越来越普及，常用于跟 IVI 系统的交互操作。进一步还能通过语音来对驾驶员进行情绪状态分析。当 DMS 系统检测到驾驶员昏昏欲睡时，系统可以通过播放音乐或者释放香味来唤醒驾驶员；基于多场景下的汽车座舱多模态交互技术未来一定会重新定义人机交互技术的发展。 所有这些智能座舱新技术的发展，都将推动对座舱域计算资源需求的暴增。 智能座舱域控制器领域，全球 Tier 1 厂商主要包括：博世、大陆汽车、哈曼、伟世通和 Aptiv （安波福）等。中国本土企业主要有德赛西威、航盛和东软睿驰等。 表 2-1 全球主要座舱域控制器厂商信息 2.2 ADAS 域控制器 ADAS 域控制器通常需要连接多个摄像头、毫米波雷达、激光雷达等传感器设备，要具备多传感器融合、定位、路径规划、决策控制、无线通讯、高速通讯的能力，要完成包含图像识别、传感器数据处理等诸多功能，因此要完成大量运算，域控制器一般都要匹配一个核心运算力强的处理器，能够提供自动驾驶不同级别算力的支持，目前业内有 NVIDIA 、华为、瑞萨、 NXP 、 TI 、 Mobileye 、赛灵思、地平线等多个方案。 自动驾驶技术目前是全球科技行业最前沿的方向。 L1 到 L2+ 级别的辅助驾驶技术和功能已经日趋成熟，搭载 ADAS 功能和应用的很多车型开始进入大规模量产。可以遇见 L1/L2 级别 ADAS 功能的市场渗透率将快速提升，而 L3/L4 级别自动驾驶系统仍处于小规模原型测试阶段。 当今的自动驾驶行业，中国市场绝对是主力。今年中国 L2 的搭载量预计突破 80 万，中国品牌占据绝大部分份额。未来中国市场 ADAS 功能的渗透率还将持续快速提高，中低端汽车所配置的 ADAS 功能将逐步增多。根据艾瑞咨询研究报告显示，预计 2025 年 ADAS 功能在乘用车市场可以达到 65% 左右的渗透率。 L3 级别的高速自动领航 HWP 功能和 L4 级别的 AVP 自动泊车功能，目前车型渗透率较低，未来提升空间较大。 图 2-4 中国 ADAS 功能市场渗透率预测 ADAS 域控制器正在从过去的分布式系统架构演变到域集中式架构。过去一套 ADAS 系统，要有好几个独立的 ECU 才能实现，比如车道偏移和交通识别 ECU 、前向碰撞预警 ECU 、泊车辅助 ECU 等。现在有了功能强大的集中式 ADAS 域控制器后，一个域控制器就实现了所有功能。系统的软硬件复杂度大大降低，可靠性也得到了提高。 目前业内提供 ADAS 域控芯片平台的有 NVIDIA 、华为、瑞萨、 NXP 、 TI 、 Mobileye ，以及国内本土的地平线和黑芝麻等多个方案。下表 2-2 总结了全球主要 ADAS 域控制器厂商及其客户和伙伴信息。 表 2-2 全球主要 ADAS 域控制器厂商信息 域控制器发展趋势 域控制器的兴起对传统的汽车 MCU 厂商造成了极大的挑战，“因为 MCU 使用量将大大减少，传统的 MCU 产品其演进路线将不复存在”。 在分布式 ECU 时代，计算和控制的核心是 MCU 芯片，传输的基础核心是基于传统的 CAN 、 LIN 和 FlexRay 等低速总线。但在域控制器时代，高性能、高集成度的异构 SoC 芯片作为域的主控处理器，将成为域控制器的计算与控制的核心芯片。而汽车 TSN （ Time-Sensitive Network ）以太网因为具有高带宽、实时和可靠的数据通信能力等特点，必将成为整车通信的核心基础设施，尤其是域主控处理器之间的通信主干网。 下面我们来简单分析一下域控制器以及核心的主控处理器的一些关键技术和趋势。 3.1 高性能 总的来说，对算力的需求提升一直是域控制器核心芯片发展的主要推动力。一方面原本由多个 ECU 完成的功能，现在需要依靠单一的域主控处理器来完成，并且还需要管理和控制所连接的各种传感器与执行器等。比如：底盘、动力传动系统和车身舒适电子系统的域主控处理器，其算力需求大约在 10000DMIPS-15000DMIPS 左右。 图 2-5 汽车域控制器对 CPU DMIPS 算力的需求预测 新的智能汽车，除了要更多的与人交互外，更需要大量的对环境进行感知，这就需要计算和处理海量的非结构化数据，因此座舱域和自动驾驶域都要求高性能的 CPU ，比如就座舱仪表的 CPU 算力而言，它其实跟一部高端智能手机的 CPU 算力差不多，约为 50000DMIPS 左右。此外，为了支持 L2 辅助驾驶功能或者更高级别的自动驾驶功能，需要运行很多视觉 DNN 模型算法，这就又额外需要上百 TOPS 的 AI 算力。 所以，各芯片厂商总是会尽量使用更先进的制程工艺、更先进的 CPU 核于与 NPU 核来尽量提高域主控芯片的 CPU 核心性能与 NPU 性能。 3.2 高异构性 伴随着 AI 技术在视觉领域的应用，基于视觉的自动驾驶方案逐渐兴起，这就需要在 CPU 的基础上加装擅长视觉算法的 GPU 芯片，从而形成“ CPU+GPU ”的解决方案。不过，“ CPU+GPU ”组合也并非最优解决方案，因为 GPU 虽然具备较强的计算能力，但成本高、功耗大，由此又逐步引入了 FPGA 和 ASIC 芯片。 总体来看，单一类型的微处理器，无论是 CPU 、 GPU 、 FPGA 还是 ASIC ，都无法满足更高阶的自动驾驶需求，域控制器中的主控芯片会走向集成“ CPU+xPU ”的异构式 SoC （ xPU 包括 GPU/FPGA/ASIC 等），从而能较好的支撑各种场景的硬件加速需求。 3.3 高集成度 从功能层面上，域控制器会整合集成越来越多的功能。比如动力系统域可能把发动机的控制、电机控制、 BMS 、车载充电机的控制组合在一起。有些主机厂甚至直接一步到位，将底盘、动力传动以及车身三大功能域直接整合成一个“整车控制域（ Vehicle Domain Controller ， VDC ）”。 要支持这些功能的整合，作为域控制器的大脑，域主控处理器 SoC 就需要集成尽可能多的接口类型，比如： USB 、 Ethernet 、 I2C 、 SPI 、 CAN 、 LIN 以及 FlexRay 等等，从而能连接和管理各种各样的 ECU 、传感器和执行器。 3.4 硬件虚拟化 对硬件虚拟化技术的需要主要来自两方面：（ 1 ）硬件资源的分区与隔离；（ 2 ）支持混合安全等级。 原本需要多个 ECU 实现的多个功能都整合到域控制器上后，势必会导致域控制器的软件更为复杂，这势必会导致整个软件系统的出错概率增加、可靠性下降。而且多个应用混合运行在同一个操作系统上，经常会出现故障传播（ Failure Propagation ），也就是一个应用出现问题后，会使得整个系统底层软件和硬件都处于紊乱状态，从而导致其它原本正常的应用也会开始出现故障。因此通过硬件虚拟化技术对硬件资源进行分区（ Partition ），使得各个功能对应的软硬件之间互相隔离（ Isolation ），以此保证整个系统的可靠性。 另一方面，在汽车电子系统中，通常不同的应用其对实时性要求和功能安全等级要求都不同。例如，根据 ISO 26262 标准，汽车仪表系统与娱乐信息系统属于不同的安全等级，具有不同的处理优先级。汽车仪表系统与动力系统密切相关，要求具有高实时性、高可靠性和强安全性，要求运行在底层实时操作系统上（比如 QNX ）。而信息娱乐系统主要为车内人机交互提供控制平台，追求多样化的应用与服务，以 Linux 和 Android 为主。为了实现混合安全等级的应用，实现不同的操作系统运行在同一个系统上，这就需要虚拟化技术的支持。 车载硬件虚拟化技术的核心是 Hypervisor ，它是一种运行在物理服务器和操作系统之间的中间层软件，可以允许多个不同虚机上的操作系统和应用共享一套基础物理硬件。当系统启动时，首先运行 Hypervisor ，由它来负责给每一台虚拟机分配适量的内存、 CPU 、网络、存储以及其它硬件资源等等（也就是对硬件资源进行分区），最后加载并启动所有虚拟机的客户操作系统。 一句话总结一下基于 Hypervisor 的优点：它提供了在同一硬件平台上承载异构操作系统的灵活性，同时实现了良好的高可靠性和故障控制机制 , 以保证关键任务、硬实时应用程序和一般用途、不受信任的应用程序之间的安全隔离，实现了车载计算单元整合与算力共享。 3.5 ISO 26262 功能安全 功能安全是汽车研发流程中非常关键的要素之一。随着系统复杂性的提高，来自系统失效和随机硬件失效的风险日益增加。 ISO 26262 标准制定的目的就是更好的规范和标准化汽车全生命周期中的功能安全管理和要求，包括：概念阶段、系统研发、硬件研发、软件研发、生产和操作过程、售后等环节，尤其重点在产品设计阶段如何定义和实现功能安全的目标。 载汽车功能安全标准 ISO26262-5 2018 “产品开发：硬件层面附录 D ”中对处理器单元的诊断覆盖率推荐的安全技术措施中，双核锁步 (dual-core lockstep) 、非对称冗余和编码计算是三种典型的硬件冗余技术措施。除此之外，硬件 BIST 、软硬件 Self-Test 技术、 ECC 等也是常见的提高处理器安全特性的设计措施。 图 2-6 ISO26262 标准中的功能安全芯片设计技术 双核锁步 CPU 是一种 CPU 冗余技术，在一个芯片中包含两个相同的处理器，一个作为 master core ，一个作为 slave core ，它们执行相同的代码并严格同步， master 可以访问系统内存并输出指令，而 slave 不断执行在总线上的指令（即由主处理器获取的指令）。 slave 产生的输出，包括地址位和数据位，发送到比较逻辑模块，由 master 和 slave 总线接口的比较器电路组成，检查它们之间的数据、地址和控制线的一致性。检测到任何总线的值不一致时，就会发现其中一个 CPU 上存在故障，但不会确定是哪个 CPU 故障。 这种 CPU 架构使得 CPU 自检独立于应用软件，不需要执行专门的指令集自检，实际运行的软件指令在每个时钟都进行比较，只需要测试软件用到的 CPU 资源，但这种架构不会对内存和总线进行检测，需要增加单独的检测方法以避免两个 CPU 的共模故障。 3.7 网络卸载引擎 汽车网络会存在多种通信总线。骨干网未来势必会基于 TSN 以太网来构建，但是从域主控处理器到 ECU 或者传感器之间的通信则仍然是基于传统的车载低速总线，比如： CAN 、 FlexRay 等。域主控处理器作为域控制器的核心，是所有 ECU 和传感器通信的汇聚中心。因此如果要依靠 CPU 的算力来完成不同总线间的协议转换，以及跨域通信的网络包处理的话，势必会占用宝贵的 CPU 算力资源。 因此基于硬件来实现网络协议转换处理的网络卸载引擎，对于各个域（包括中央网关）的域主控处理器是非常重要的技术。 3.7 Security 引擎 连接性（ Connectivity ）是汽车智能化发展的一个很重要的趋势，未来的汽车一定会像今天的手机一样随时保持连接到互联网中。因此如何阻止未经授权的网络访问，以保护汽车免于受到黑客的攻击，对未来的智能汽车而言就会变得极为重要。下一代硬件安全模块（ Hardware Security Module ， HSM ）正在成为下一代车载网络通信的重要基础设施之一。 HSM 对于完全的安全车载通信（ Secure Onboard Communication ， SecOC ）是必不可少的。 HSM 能确保所接收到的数据的真实性，防止攻击者绕过相关的安全接口，入侵车载网络。 基于硬件的安全模块主要解决两个问题： 密钥泄漏问题：如果密钥存储在应用程序的代码或数据中，很容易被泄漏。所以有必要增加一个硬件模块，专门存储密钥。 Crypto 算法加速：通过内核来直接进行加密或解密运算会占用大量 CPU 算力资源。因此，有必要通过硬件模块来进行加密解密算法的加速。 SHE （ Secure Hardware Extension ）标准是由奥迪和宝马公司合作制定的、针对硬件安全模块 HSM 的规范，它主要包括密码模块的硬件、硬件软件接口。这个规范已被广泛接受，很多针对汽车行业的微处理器都支持这个规范。 3.8 面向服务的软件架构 SOA ECU 原先运行的软件大多数是按照 Classic AutoSAR 规范开发的软件系统，其中的应用软件一般都是静态调度（ Static Scheduling ）模式的，也即在系统运行时，程序中不同功能的函数按照事先定义好的排序文件依次调用、逐个运行。静态调度的优点是资源分配问题都是事先安排好的，车辆量产后就不会再改变，每个功能对应的函数代码具体运行时间也被提前锁定，是确定性的。因此这种设计对于汽车上很多对功能安全要求苛刻的场景是非常适合的。比如：决定安全气囊是否打开的功能函数就是固定地每隔几毫秒运行一次，以便紧急情况下可以及时打开。 承载计算和控制的底层硬件从分散的多个 ECU 集中到多核、异构的高性能域主控处理器后，相应的软件也会从分散向集中、从简单向复杂、从静态向动态进化。下图 2-7 显示了以后汽车域控制器上的典型软件架构： 图 2-7 域控制器上基于空分虚拟化技术的典型软件架构 操作系统层：最底层利用 Hypervisor 虚拟化技术对硬件资源进行分区 (partition) ，从而可以在每个虚机运行不同的操作系统。比如在上图中，虚机 VM1 中运行兼容 POSIX 实时操作系统标准（比如 PSE 52 ）的 RTOS ， RTOS 上通常要承载功能安全相关的应用和服务；虚机 VM2 中运行 Linux 这种完全 POSIX 标准的分时操作系统，上面通常运行管理相关的功能和服务；虚机 VM3 中运行的可能是原来在 ECU 上运行的 Legacy 应用。 中间件层：操作系统是不做任何与 “车”特定相关工作的。为了让域主控处理器在汽车场景下使用，需要有很多软件或者中间件用于让域控制器满足汽车的电源管理标准、网络管理标准以及诊断标准等；车载域控制器需要比一般工业嵌入式系统有更高的可靠性要求，这样就需要在计算机 OS 基础上再附加对存储和通讯等各方面的安全保护和容错机制；同时，位了让车载域控制器能够在整车 EE 架构下运行，还需要提供时钟同步、日志跟踪以及服务管理和发现等功能。 Adaptive AutoSAR 规范定义了运行在 Linux 或者完全兼容 POSIX 1003.1 标准 RTOS 上的这一层与“车”相关的中间件标准；而传统运行在 POSIX 子集的 RTOS 或者 BareMetal 模式的中间件规范则由 Classic AutoSAR 标准定义。 应用层：上层应用基于 AutoSAR 标准的中间件来进行开发。随着汽车智能化和网联化相关的功能越来多，上层应用软件也越来越复杂。位了降低单个应用的整体复杂性，我们可以借鉴互联网的面向服务架构（ SOA ）的软件设计思想，将一个复杂应用拆分多个服务。每个服务实现得尽可能小，尽量实现成无状态方式的服务，以利于整个系统的开发、测试和软件重用。服务与服务之间通过事件或者消息总线（发布 / 订阅工作模式）来进行通信，并降低互相之间的耦合度。通过服务配置来管理服务之间的依赖性、服务的部署和启动，以及服务的健康状态检测等。 汽车以太网给车载系统通信带来一个革命性的变化，在中央计算式汽车 EE 架构下，整个车载系统可以被看作是一个分布式网络系统：中央计算平台是一个小型服务器集群，区域计算平台是边缘计算节点。在互联网或者大型分布式系统中， SOA 架构设计理念已经被广泛使用了。因此当 IP 网络技术被广泛应用于汽车后，很多在互联网或者分布式计算中已经很成熟的软件技术，自然会被借鉴到新的汽车软件架构设计中来，比如： RPC 技术、事件 / 消息总线、 RESTful API 设计等。 大型互联网数据中心中的服务器集群动辄几百、上千台服务器，每秒百万、千万级别的并发。车载系统尽管可以被看作是一个分布式网络系统，但是它却没有互联网大型服务器系统的高并发特征，相反，它更注重通信的实时性和可靠性。 车载系统在物理上是向集中式发展的，也就是原来通过多个分散 ECU 来实现的功能，渐渐集中到几个主要的高性能域控制器上。因此，尽管在软件设计上，我们会尽量按照 SOA 的思路拆分成一个一个小的服务，但是这些服务在部署上其实是集中式的。鉴于这种物理部署上的“集中”与运行时的“分布式”并存的特点，因此我们可以通过一系列技术手段来优化服务与服务之间的通信延迟（比如：通过共享内存技术）。这是车载分布式系统与互联网强调高并发特性的分布式系统之间另一个显著的差别。 小结 域集中式 EE 架构会是未来相当长一段时间占主要地位的汽车 EE 架构，域控制器作为域集中式 EE 架构的核心，会在整个汽车产业链中占据越来越重要的地位。其相应的芯片和硬件方案、操作系统和算法等将会成为整个产业链各上下游厂家的争夺焦点。 关注公众号“优特美尔商城”，获取更多电子元器件知识、电路讲解、型号资料、电子资讯，欢迎留言讨论。

随着ECU功能的增加和平台化的推广，标定的需求正在从动力系统和底盘系统向车身系统和娱乐系统扩展。由德国Vector公司提供的CANape主要用于ECU参数优化（标定），可在系统运行期间同时标定参数值和采集测量信号。 CANape与ECU的物理接口可以是使用CCP（CAN标定协议）的CAN总线，或者是使用XCP协议的其他总线。另外，CANape集成了强大的离线数据分析功能，通过数据挖掘，能够自动的批量分析，评估测量数据，并自动生成分析报告；其集成的CDMstudio工具提供图形化的视图，方便用户对标定参数文件（如PAR，DCM，CDFX等），HEX文件进行对比，修改，合并等。 客户 HOERBIGER是汽车传动和离合器方面的专家，在全球汽车行业中颇受赞誉。它致力于开发针对运动型轿车和高档轿车的双离器合系统以及针对乘用车和商用车的同步传动系统。 挑战 如何便捷地测试Simulink模型的行为？ 在针对第二代双离合器传动的软件开发中，工程师将现有的、手动生成的C代码转换为MATLAB/Simulink模型。之后，由模型生成的代码直接集成于AUTOSAR RTE。每个软件模块都可以用Simulink模拟。然而，现有的MATLAB Scopes可视化选项不足以进行详细的数据分析。优化参数的过程也是费时而不便的，按要求需修改MATLAB Workspace中的值或生成特定的GUI元素。 解决方案 针对Simulink模型以及ECU内部数据的参数化和可视化，选择CANape作为 用户接口。 连接CANape和Simulink模型最简单的方法就是用Simulink XCP Server。用户使用时同与ECU连接时相同：从描述文件中选择测量量及标定量，并拖动到显示及标定窗口中显示。按下一个按钮，可从Simulink模型生成必要的A2L描述文件，无需额外的仪器就可读写模型中的参数。 优势 --Simulink模型可实现可视化和参数化 --高效、便捷 --CANape Option Simulink XCP Server非常适合于分析模型的行为： 在整个开发过程中，CANape配置同标准的XCP协议配置相同。无论模型、快速原型平台或ECU连接皆适用。 尽可能切合实际地测试模型，记录的测量数据可作为输入参数回放到模型中运行。 在CANape的各种窗口中很容易观测测量数据以及对标定数据进行修改。不需要针对模型的特定设备。 带CDM Studio的标定数据管理系统（Calibration Data Management）便于编辑和管理模型中的参数集文件。用户可以复制、合并不同的参数集，下载在Simulink模型中并将参数以不同的格式如MATLAB M-script格式保存。 仿真结果可用MDF格式保存。实现从汽车上测量的数据和从CANape中通过手动或自动评估得到的数据的直接对比。 解决方案是可扩展性的：针对计算量特别大的模拟，可以将处理器负载分布到2台计算机。