未来的汽车电子会发生哪些变化 ？
Vehicle攻城狮
The people who are crazy enough to think they can change the world are the …
⚠ 全文总长约含2900字，预计您的阅读时间为7分钟公众号：汽车ECU设计 (ID: QCECUSJ)
引
目前的汽车有多达几十甚至上百个电子控制单元并连接到多种总线上，平均来说，目前的汽车大约采用25个ECU，但一些高端车型已经超过100个ECU。在过去，汽车电子电气架构一直遵循着“一个功能一个盒子”的分布式架构模式。如变速箱控制由TCU负责，发动机控制由EMS负责，虽这两个同样在动力域但分别由供应商提供各自的硬件和软件。在这样的汽车电子电气架构形式下，每增加一个功能，就需要动相应的控制器，涉及多方的交流和维护成本，进一步增加系统的复杂性和成本。最终会导致一个规模更大且复杂的车载网络和布线，也从另一方面影响整车的轻量化。
1
域控制器
面对汽车功能和软件复杂度的提升，需要对汽车E/E架构进行重构，建立更加灵活的体系架构。域控制器也是最近这些年才热起来的，所谓的域就是将整车划归为不同的区，如动力域、车身域、底盘域、娱乐域等，每个域只挂载单个控制器来负责所在域的功能，减少之前一个功能、一个“盒子”的分布式E/E架构复杂的布线和集成：其实就是将多个控制器的软件糅合进一个控制器，例如对于纯电车，动力域有BMS、MCU、VCU、DCDC等控制器，将这些控制器的功能全部放在一个控制器里，并交给一方来做，不仅省了其他控制器硬件成本的钱，也减少了交互沟通的成本。
域控制器可大大降低控制器数量和整车布线，而多核异构芯片、Hypervisor等技术都从软硬件方面为域控制发展和应用提供了支持。目前BOSCH等供应商都已有相应的域控制器产品，但实现真正的域集中E/E架构依然还需要很长时间，毕竟这不是一己之力才能实现的，需要OEM、供应商等共同大力合作和推进才能实现。例如同一个域控制器中软件可能由多个供应商提供，每个供应商除了负责各自软件的升级，还涉及复杂且不同类型软件的集成和测试，那么使集成和升级工作变的相对容易些就是一个问题。再比如不同域的域控制器由不同供应商与OEM合作开发，又会带来很多新的问题。
而域控制器最终的目标是中央计算机架构，中央计算机由异构的多核处理器构成，将整车功能集中到一起。
2
SOA 面向服务
SOA是一种软件架构，同时也是一种软件设计方法和理念，在IT领域已有数十年的应用经验。SOA具备 “松耦合”、”接口标准可访问”和”易于扩展”等特点，使得开发人员能以最小的软件变更应对迭代多变的客户需求。
服务高内聚，软件易重用：一个服务往往只关注一件事并把这件事做好，这件事的内容（功能）需要从业务的角度进行梳理服务的灵活部署：通过服务发现机制，可在控制器运行时获取服务的位置和提供方，并可在整车生命周期内调整服务角色的部署位置，使功能分配更灵活软件更新升级更快捷：一个功能改变可能只需要升级和更新一个服务，而且服务是一个独立可执行单元可单独安装升级，因此软件维护和扩展更容易。
因此基于上面的优势，伴随着汽车智能化、网联化、共享化的趋势，终端用户对车辆功能的预期也悄然发生着改变，汽车在实现高等级自动驾驶/辅助驾驶功能的同时，也更趋向于提升用户体验，例如满足快速的功能更新和升级，可以提供个性化、人性化、差异化的功能与服务等。
3
合作共赢
继开创“软件定义汽车”的特斯拉风生水起后，一时“软件定义汽车”的妖风四起，在大众成立软件开发独立部门之后，丰田也正式成立软件子公司-Woven Planet Holdings，专注于开发自动驾驶、新的汽车操作系统以及高清地图等软件业务。国内上汽等主机厂也纷纷成立自己的软件中心，例如上汽的零束，都想在这次变革中掌握软件开发的主动权。
类似BOSCH、大陆等这些跨国500强，在这些零部件的软硬件开发上经验丰富，产品迭代了几十代，无论从成本还是稳定性，相比整车厂自己开发的软件可以说是碾压的存在，而且还有专利加持，整车厂转型软件可以说是举步维艰，就拿 ESP 车身稳定系统来说，日系的厂家开发出了同样的功能，但是由于专利限制，甚至连 ESP 的名字都不能叫，改名 VSC ，可想而知其在开发阶段为了规避专利风险，到底饶了多少弯路。这些对于要转型软件开发的整车厂也是一样的，行业壁垒不是那么容易破除。再有就是实实在在的高端软件人才吸引能力，汽车属于典型的重资产行业，要造车的话需要买地建厂买设备建产线，而当前火热的软件开发IT 行业，人的工资就是最大的投资成本，说白了，汽车行业软件从业人员的公司，和互联网无法站在同一竞技擂台上进行比对，所以整体上是缺少高端软件人才的，这样造成了当前整车厂软件开发的转型困境。
基于如上几点，整车厂已经发现软件开发不在是传统的单个工厂物料而已，很快就会成为自家公司的核心竞争力，所以开始下重力气建立软件研发团队，进行核心软件开发。尤其目前智能化、网联化和电动化的趋势下，使大家最大程度的站在了同一起跑线下，因此整车厂想从之前的“组装厂”模式开始研发和生产自己的软硬件，并自己进行产品的改进和价值创造。因此在这种趋势下，以前供应商全包的模式将逐渐弱化，而是与OEM合作开发的模式。
4
多核处理
汽车电子电器架构和整车功能越来越复杂，需要计算能力更强大的硬件来支持越来越复杂的软件功能，随着ADAS、自动驾驶等应用场景的加入及未来域集中甚至中央计算机的E/E架构变更，多核系统的需求将更加明显。
当然多核系统的软件开发集成相比单核，在项目时间、复杂度、成本以及给攻城狮带来的额外工作量都是成倍增加的。多核处理器的应用也会带来诸多挑战，例如满足ISO26262功能安全的挑战、合理分配各核计算负载、多核系统数据一致性挑战等等。
5
软件架构
软件架构这部分，我们抛开一些闭源的诸如特斯拉的软件，来谈谈大家普遍接触的的Classic Autosar和Adaptive Autosar。我们整车上的控制器，分动力域的控制器，如发动机控制EMS、TCU等，还有信息娱乐域的控制器比如车机显示灯，不同控制器的实时性要求等方面是不一样的。例如发动机控制器ECU、或者整车控制器VCU实时性和功能安全要求要比与其他功能或信息娱乐性控制器高，动力域的基本基于Autosar经典平台开发，因其具有如下特点：
硬实时，可在微秒内完成事件的实时处理，硬实时任务必须满足最后期限的限制，以保证系统的可靠运行高功能安全等级，其可达到ASIL-D的安全等级对CPU、RAM或Flash等资源具有较低的占用率软件功能通常是固化不可动态变更的
而信息娱乐性控制器，则正好与上相反，其一般会占用较大的硬件资源，且一般实时性要求相对低，因其一般运行在嵌入式PC上，如LINUX，而不是汽车级操作系统上，所以其即使出现故障也不会造成严重的安全事故。而ApdativeAutosar则是连接这两者的桥梁，其具有如下特点：
软实时，具有毫秒级内的最后期限，且偶尔错过最后期限也不会造成灾难性后果具有一定的功能安全要求，可达到ASIL-B或更高与经典平台不同的是，它更适用于多核动态操作系统的高资源环境，如QNX
Adaptive Autosar与Classic Autosar相比，虽实时性要求有所降低，但在保证一定功能安全等级的基础上，大大提高了对高性能处理能力的支持，以支持智能互联应用功能的开发，因此C++将成为AdaptiveAutosar平台的主要开发语言。
Adaptive Autosar的出现并不是为了取代ClassicAutosar平台，而是针对不同的应用场景实现两者的共存和协作，Classic Autosar平台支持高安全性和高实时性的应用场景，因此对于深度嵌入式的软件功能需部署运行在经典平台上，而Adaptive Autosar则支持并行处理的需要高性能运算的功能则需要运行在Adaptive平台上。当然在软件架构方面本来是多样的，采用哪种就看主机厂如何考量和能力如何了，多软件架构，诸如Autosar、Adaptive Autosar、ROS等将会耦合集成。
完
推荐阅读
汽车ECU设计
一个菜鸟程序猿的成长之路。116篇原创内容
公众号
↙戳链接一秒找到我
有观点分享，请留言↘
阅读原文