金脉电子秦晨：动力系统域控制器开发的思考及挑战

大家好，我的分享内容主要包括以下几个部分。

第一，我们为什么需要开发域控制器，域控制器并没有给车辆带来新的功能，为什么到处都在提域控制器。第二，动力系统域控制器可能会是一个什么样的形态，我会通过一个案例给大家介绍一下我们给客户开发的一款动力系统域控制器。第三，从功能安全开发包括软件架构、软件系统集成这两个不同的维度探讨对于域控制器的开发和设计可能会面临一些什么样的问题和挑战。

这张图大家都很熟悉，软件定义汽车以及基于域的架构，现在不光有域控制器的开发，越来越多客户开始探讨针对Zone架构的开发。但是根据一些咨询公司的报道和分析，在全球来看，域控制器在当前市场占比还是比较小的，未来5年时间可能会占所有电控系统五分之一的份额。我们认为对于域控制器的开发，整个行业发展需要经历一段时间。对于车辆来说，我们现在初步分析，对于传统汽车整个电子系统域控制器发展比较缓慢，因为大部分核心零部件会由Global供应商提供；而新的E/E架构将导致供应链会产生一定的变化，这需要大量的供应商支持。现在来看，电动汽车的动力系统和自动驾驶系统两个系统向基于功能域架构，也就是域控制器的演进相对比较激进；整车来说车身系统向域包括中控集中式演进相对较慢。

为什么需要动力系统域控制器，我们做了一个对比，底下是基于传统架构的示意图，上面是基于域的架构，传统架构存在一些跨功能的连接。谈到对于动力系统域控制器，绝大部分开发者第一个能想到的是它可以降低系统的硬件成本。我们把降低系统的硬件成本列到最后一条，因为对于域控制器来说很直观地反映，可能两个控制器会变成一个控制器，物理成本上以可以节省掉一个单片机、电源、连接器，这些都是很直观地能反映出成本降低的因素。但是这样的思路往往会导致系统集成商、主机厂陷入线束成本的黑洞，所以我们会把它放在最后一条。基于域的设计可以降低整个系统软硬件的复杂度，是一个相对的概念，针对域的架构我们一定程度上可以抽象地理解成整个控制的功能、复杂的逻辑都集成到了域控制器，相对来说其他的包括感知、执行等等这些偏向于IO功能的模块放在了域内的ECU。我们把软硬分离或者软硬解耦的概念用到了整个系统级别，所以才会出现动力系统域控制器，这会导致整个系统的软硬件复杂度相对比较低。原先可能这里（传统架构中的ECU）全部都是32位多核单片机，在理想的模型下有可能这边（域控制器）会是多核的单片机或者处理器，底下每一个执行机构的小ECU可能有16个单片机或者不需要单片机，这是指降低软硬件的复杂度。还有一个是相对更低的系统成本，原先的架构对于一个复杂的功能，比如电动汽车油门踏板踩下去到转矩输出，这样的功能要经过VCU、MCU，同时BMS还要监管此刻电池温度是否过热，如果过热要限功率，这个功能由很多模块分布来实施。验证这个功能，需要验证MCU、BMS等多个单元。对于域控制器来说底下这些都是单纯的I/O模块，只是被动执行指令，这种架构针对每一个ECU验证比较简单，每一个ECU的验证和其他ECU之间的协同变得更少，主要复杂功能的验证全部集中在（域控制器）这里。整个系统比如4个供应商对其他3个测试验证的要求大幅度降低，降低他们的开发成本，只需要对其中一个（域控制器供应商）提高要求就可以，这是降低系统的验证成本。底下一条是经常会碰到的就是软件的更新会变得更简单，因为软件更新也是现在OTA经常提到的概念，针对域的架构，如果我们常见的这里的ECU需要做代码更新，绝大多数情况下意味着这里修复一个Bug，我们认为对于量产车来说它的评估应该是非常低的。只要把这个域控制器刷掉，基本上整个相关的功能全部得到了更新。最后一条才是降低系统的硬件成本。这是我们理解为什么对域控制器有需求，域控制器的推进力一方面可能会和技术有关系，因为软件会变得更复杂，软硬件进一步解耦。另外一个层面的推进力是由业务端引起的，最终我们的主机厂可能会希望得到更优化的成本。

基于这些因素，我们进一步分析为什么会有各种各样形态的域控制器，包括域控制器的开发和设计过程当中需要有哪些注意的地方。我们看到，针对不同车型有提出要VCU+BMS的，也有人提PEU+GCU+VCU+HCU，各种各样的组合都是从系统集成商的角度来看，基于上述的出发点他们满足了特定的条件才会有特定的组合。我们不认为特定组合的DCU一定在产品或者技术上有绝对的优势，这张框图包括了最典型的电动汽车的电驱动系统，包括VCU、Inveter、电机、电池包。去年我们给一个客户做过一个方案，当中他们将BMS和VCU进行整合，将部分BMS硬件的功能和PDU做了整合，成为了HVCU。最后集成了VCU和BMS的域控制器就是如图这样。这个产品从形态上来说大家会觉得和原来的VCU没有什么区别，和原来的BMS也没有什么区别，实际上从域控制器来说它最终的形态还是一个控制单元，并没有形态上有什么太大的演进。域控制器和DCU、ECU最大的区别不在于硬件，而在于软件和系统。域控制器的开发，是我们尝试在同一个嵌入式系统或者电子系统里面让它实现更复杂的功能，所以我们建议大多数设计人员在考虑ECU的时候不要过多地关注于硬件。

后面我们从系统和软件集成的角度看一下域控制器的集成大概会是什么样的过程。这张框图是代表整车的网络架构，今天主要讨论的是动力系统域部分，我们列出了动力系统域中一些最典型的通常会包括的模块，VCU、MCU、PDU、BMS、OBC，比如说像VCU、MCU基本上都是ASIL C，有些厂商会要求ASIL D，对于PDU和OBC，一般建议安全等级在ASIL B以上。这里列举了一个非常典型的三层安全架构，我们认为主要的功能安全的控制器基本上都可以把它的整个架构按照三重架构分解，包括以下单元：第一，功能逻辑层，这一层主要实现具体的功能，以MCU为例，MCU这个层基本上主要是控制功能，将得到的命令输出扭矩；第二层是对它的功能进行监控，要确认输出的扭矩是符合转矩命令和要求的，对于VCU来说也有类似的要求，第一层是油门踏板，输出的是对应的转矩，VCU是要监视油门踏板是什么输出信号，是不是符合预期或者在合理范围内，这是一个非常典型的架构。

系统设计的角度来看如果将这些控制器做系统集成，如果我们要把它从5个控制器变成1个控制器或者其中一部分控制器变成一个或者把它的功能这一层集成起来，一定程度上要看怎么将原有的架构变成新的架构来满足我的要求。这里我们通过3个不同程度的色块表明它的L1、L2、L3，集成的过程当中我们假定将5个控制器变成1个控制器，这是一个最极端的做法。原有的控制器当中每一个都会有它自身的L1、L2、L3，集成后目标DCU会是一个什么样的架构呢？曾经我们碰到一些极端的客户，这边如果是5个控制器，他们在目标控制器里面就是五个L1、L2、L3，全部放进去。这样会是一个什么结果呢？比如现在大家在做的会有很多涉及到MCU或者VCU开发，典型的MCU上比如用到一个三核单片机，目前很多客户用的是TC277或者TC275，如果五个都是TC277，把五个L1、L2、L3拼在一起，需要15核的单片机或者处理器。一种是目前没有这样的东西，还有这个也不符合我们对于DCU基本的需求，我们对于DCU的需求是通过系统集成的手段从系统端降低对于成本的要求，并不是简单的物理集成。我们认为集成后DCU可能的情况，五个L1可能会变成四个，因为做系统集成的时候原先有一部分分散在每一个ECU的功能会被逐步整合，所以集成后功能实现层的模块数量可能会变少。L2的数量发生了明显变化，可能变成了只有两个，当然也有可能只有一个，因为功能集成以后，对于功能检测和功能诊断的方式需要改变。举一个最简单的例子，从电路的设计上来说，有两种检测方式判断这个电路是否正常，一种是对于电路的每一个元器件做失效检测，这种是最底层的诊断和检测，需要的代价很大。另外一种方式只看输入输出，因为在一个需要做闭环控制的场景下输入输出一定是会自己拿回来做检测的。通过输入输出，只要输出不正常，电路一定有问题，可以不需要关心这里面是哪一个电路失效。越是高等级的安全机制越是意味着整体成本会低，在系统集成的过程当中我们一定会需要把若干个L2的安全机制合并。这边（原先一个ECU中的L2）是277的一个核，这边（原先另一个ECU中的L2）也是277的一个核，把这两个合掉节省出来一个核资源。按照三层架构来说L3绝大多数场合是保证L2正常运行，对于实际实施来说保证嵌入式系统在正常工作。具体案例来说这里可能是TLF35584和AURIX内部安全机制的配合工作。如果这里（集成后的DCU）用单一的处理器或者一个单片机来做，可以用一个L3的单元解决这个问题。从整个系统设计来说，这样的结果可以大幅度对原先的东西进行优化。原有的系统比如说（MCU）TC277、（VCU）TC277、（BMS）TC277，还有其他的ECU，一共会需要10个核以上；现在需要多少？6个核！我们希望能够通过这样的案例来体现DCU对于原有系统可能实现极大优化的原因。这里分享一个我们之前的实际案例，将两个原先使用TC277的ECU进行集成，最后的DCU产品是基于TC387的，它的一个四核的单片机。

我们在这里也解释一下安全相关的系统集成可能会带来一些什么样的问题：一方面是在这种系统集成的方式意味着整个安全机制要重新设计，功能安全的开发需要做大量的验证，而且对于开发流程有很多要求。如果想按照这样的系统去做实施，以这样的目标为实施，前期开发是需要投入大量资源的，包括可能会有额外的开发周期。你的系统集成度越高，开发周期一定越高。

另一方面，它可能的好处，我们之前用AURIX二代换掉了AURIX一代，我们沿用了原有的L3的安全机制，对于单片机系统或者嵌入式系统监测的机制将有可能得以保留。这块我们之前也和业内同行有交流，他们切换一个单片系统，如果是安全系统相关的其实非常痛苦而且会花很多时间。

最后我们可以从软件架构设计和系统集成的角度看一下域控制器集成可能会有什么样的问题，举一个例子，假定有若干个核的ASIL D的单片机，动力系统上应用的单片机基本上一定是ASILD。这里面包括多个输入输出，包括传感器、执行器、通信接口等等，分配在不同的内核上。我们可能会有很多功能，这些功能也会分别部署在不同的内核上，这是大家比较长江的域控制器场景。第一，从软件架构设计来说可能是6—10个核的处理器，怎么分配，将什么样的Application放在哪个核上，这是软件架构需要考虑的问题。这本身是有迹可循的，还是以刚才那个为例，如果集成VCU、MCU，不同的Application的安全等级是不一样的，因为我可能面临着集成不同等级的软件，按照软件安全性的设计要求，这些Application是需要能够实现互相隔离，保证他们之间互相不会影响。要实现隔离有一些芯片本身内部是有一些类似于MPU的硬件单元，通过MPU单元可以保证对应的memory不会被误操作。另外，这些Application之间从宏观逻辑上是无法完全独立，一定需要有一些信号的传递：我可能这里是一个安全检测机制，VCU踏板踩的深度和转矩在这里面一定会有一些信号交互。这些信号交互的方式是什么，用共享内存，共享内存怎么保证我这里写的共享内存不会被你误写掉？这也和芯片选择有关，有一些芯片可能提供的核间通讯只有共享内存，核间通讯数据交换方式上缺乏保护机制，这种芯片或者处理器不是很理想。我们曾经和一个做航空航天的安全专家聊到类似问题，他们曾经举了一个极端的例子——大飞机，大飞机上有一个案例，之前他们也是用了一个多核的处理器，为了保证数据之间的互相隔离是安全的，他们无法用芯片共享内存满足这个要求，最后把这些核弄了一个以太网接口，通过片外转一下来实现数据交换。在安全要求很高的系统里面共享系统、数据交换是必须考虑的点，是无法绕开的，这是一个问题。

还有一个问题，操作系统，这里面涉及到不同的Application，比如说我原先这里面可能面临着需要去整合不同厂商来的软件，是不是每一个厂商的操作系统都是一致的，我们知道有一些PDU或者OBC原来的ECU里面可能不包括操作系统，现在把这些东西都搬到操作系统上，可能会导致额外工作量以及成本支出。另外目前在电驱动行业或者汽车行业Application的操作系统的供应商有好几家，宏观定义上是为软件解耦提供了标准化接口，但是基于我们的经验，如果你做了一个应用层的软件，现在想换到别的平台上，每一家的工具体系都不完全一样，每一家的解决方案多多少少会在标准的基础上加入自己的诠释，尤其工具和接口上。在做软件集成的时候怎么样统一规划网络化平台，多核系统当中也不是说必须要上AUTOSAR，可以6个核跑4个核不跑，但是不跑你AUTOSAR很难绕开功能安全的问题。

还有涉及到软件集成的问题，为什么我们一开始就将这个Application的颜色标成白色，这两个黑色。做系统集成的过程当中我们了解到的绝大多数域控制器集成都是由OEM驱动的。作为系统集成商对于这个部分可能会需要集成BMS、MCU等等，供应商提供的这部分代码往往是黑盒的，这样就引出了一个问题，可能需要面向黑盒的软件集成，这样的工作在ECU或动力系统开发团队都是缺乏经验的，这是传统IT行业更擅长的，这个问题怎么解决？

还有如果考虑面向SOA，我们会希望这个部分是可以被替换的，因为基于一个标准架构这个部分是可以被替换的，从整个软件架构的设计来说要实现软件之间的解耦。最早的AUTOSAR和AUTOSAR方法论实现的是什么？是在一个控制器内的软件和硬件的解耦。基于域的架构的概念，是在一个系统级，而不是一个控制器，内实现了软件和硬件的解耦。整个复杂控制器的环境下要实现这样的功能集成，一定程度上要关注的是软件和软件之间的解耦，如果软件之前无法进行解耦，想实现一个对于部分代码是黑盒的集成是很痛苦的。如果能够实现软件解耦，这个模块能够进行更快速的迭代和升级。那么需要怎么有效的实现解耦呢？我们现在正在做的方案用Hypervisor。在汽车电控领域hypervisor一直在发展，2015年就已经有公司尝试在TC275上跑Hypervisor了，。我们通过Hypervisor可以解决几个问题：第一，可以更好地实现软件和软件之间的隔离；第二，可以实现软件的解耦，而且我们现在在新的下一代处理器上基本上都是可以面向Hypervisor的，而且Hypervisor也是能够满足功能安全的要求。

我的分享就到这里，谢谢。