一、汽车E/E架构：分布式->域集中->中央计算机
目前的汽车有多达几十甚至上百个电子控制单元并连接到多种总线上，平均来说，目前的汽车大约采用25个ECU，但一些高端车型已经超过100个ECU。在过去，汽车电子电气架构一直遵循着“一个功能一个盒子”的分布式架构模式。如变速箱控制由TCU负责，发动机控制由EMS负责，虽这两个同样在动力域但分别由供应商提供各自的硬件和软件。在这样的汽车电子电气架构形式下，每增加一个功能，就需要动相应的控制器，涉及多方的交流和维护成本，进一步增加系统的复杂性和成本。最终会导致一个规模更大且复杂的车载网络和布线，也从另一方面影响整车的轻量化。
面对汽车功能和软件复杂度的提升，需要对汽车E/E架构进行重构，建立更加灵活的体系架构。域控制器也是最近这些年才热起来的，所谓的域就是将整车划归为不同的区，如动力域、车身域、底盘域、娱乐域等，每个域只挂载单个控制器来负责所在域的功能，减少之前一个功能、一个“盒子”的分布式E/E架构复杂的布线和集成：其实就是将多个控制器的软件糅合进一个控制器，例如对于纯电车，动力域有BMS、MCU、VCU、DCDC等控制器，将这些控制器的功能全部放在一个控制器里，并交给一方来做，不仅省了其他控制器硬件成本的钱，也由对接多方转为对接一方，想想也美滋滋。
域控制器可大大降低控制器数量和整车布线，而多核异构芯片、Hypervisor等技术都从软硬件方面为域控制发展和应用提供了支持。目前BOSCH等供应商都已有相应的域控制器产品，但实现真正的域集中E/E架构依然还需要很长时间，毕竟这不是一己之力才能实现的，需要OEM、供应商等共同大力合作和推进才能实现。例如同一个域控制器中软件可能由多个供应商提供，每个供应商除了负责各自软件的升级，还涉及复杂且不同类型软件的集成和测试，那么使集成和升级工作变的相对容易些就是一个问题。再比如不同域的域控制器由不同供应商与OEM合作开发，又会带来很多新的问题。
域控制器最终的目标是中央计算机架构，中央计算机由异构的多核处理器构成，将整车功能集中到一起。
二、在基于信号通讯的基础上引入面向服务（SOA）的通讯，并融合两者的优势
基于信号的通讯方式，即信息发送者不Care谁接收而只负责将信号发送出去，接收者也不Care是谁发送的而只负责接收自己的想要的即可。基于信号的通讯可将某节点的某信息通过总线传送给需要该信息的其他节点，信息主要为一些物理状态值及一些控制值，如发送机转速、车速等，信号有周期、事件或混合触发方式。
基于信号的通讯是目前车载总线普遍采用的，如控制器之间通过CAN总线进行的信息传输，我们关注的是通讯矩阵上的帧、帧中所包含的信号、周期和交互的节点等信息。
SOA是一种软件架构，同时也是一种软件设计方法和理念，在IT领域已有数十年的应用经验。SOA具备 “松耦合”、”接口标准可访问”和”易于扩展”等特点，使得开发人员能以最小的软件变更应对迭代多变的客户需求。迄今为止，对于面向服务的架构（Service-Oriented Architecture，SOA）还没有一个公认的定义，许多组织从不同的角度对 SOA 进行了描述，较为典型的有以下三个：
（1）W3C 的定义：SOA 是一种应用程序架构，在这种架构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成业务流程。
（2）Service-architecture.com 的定义：服务是精确定义、封装完善、独立于其他服务所处环境和状态的函数。SOA 本质上是服务的集合，服务之间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务之间需要某些方法进行连接。
（3）Gartner 的定义：SOA 是一种 C/S 架构的软件设计方法，应用由服务和服务使用者组成，SOA 与大多数通用的 C/S 架构模型不同之处，在于它着重强调构件的松散耦合，并使用独立的标准接口。
那如何理解SOA呢？理解SOA要以下面的例子先了解服务、服务接口和服务相关角色三个概念：
服务指的是某种功能的函数或方法，如上面的Weather Service和Map Service可分别提供天气和地图信息，就是一种服务。而服务接口则是服务与外界联系的窗口，及作为服务模块与外界能够进行信息交互的API。
常用的服务接口有方法Method、事件Event和字段Feild（可参考本公众号车载以太网那两篇），如下：
服务相关角色我们常接触的有服务器端Server、客户端Client和服务注册和代理方，首先服务注册和代理实现服务的注册/订阅/发布等；客户端用于使用服务接口调用使用服务，而服务器端则用于实现服务。
汽车为何要引入SOA？首先基于SOA的通讯方式有如下优点：
1、服务高内聚，软件易重用：一个服务往往只关注一件事并把这件事做好，这件事的内容（功能）需要从业务的角度进行梳理，
2、服务的灵活部署：通过服务发现机制，可在控制器运行时获取服务的位置和提供方，并可在整车生命周期内调整服务角色的部署位置，使功能分配更灵活。
3、软件更新升级更快捷：一个功能改变可能只需要升级和更新一个服务，而且服务是一个独立可执行单元可单独安装升级，因此软件维护和扩展更容易。
因此基于上面的优势，伴随着汽车智能化、网联化、共享化的趋势，终端用户对车辆功能的预期也悄然发生着改变，汽车在实现高等级自动驾驶/辅助驾驶功能的同时，也更趋向于提升用户体验，例如满足快速的功能更新和升级，可以提供个性化、人性化、差异化的功能与服务等。面向服务的软件架构(Service-Oriented Architecture)正为未来的车辆软件服务提供良好的解决方案。不同于传统汽车电子电气架构中面向信号的架构，面向服务的软件架构(SOA)通过标准化的服务接口，松耦合的服务机制以及可组合扩展的服务特性
基于上面的介绍，基于信号的通讯仅支持发送和接收模式，支持的数据类型简单且可扩展性差，适用于有限大小数据交互的应用场景。而诸如自动驾驶等先进应用场景加入后，大量数据的动态交互必须采用面向服务的通讯方式以提高通讯效率降低负载，在该种方式下，接收者作为客户端，只需要查找、订阅服务等待接收信息即可，而发送者作为服务提供者只需要给订阅者提供服务和信息即可，因基于SOA的通讯支持请求/响应模式，可扩展性强且支持复杂数据的传输，因此应发挥各自优势。
三、软件合作模式：灵活丰富的合作开发模式
继开创“软件定义汽车”的特斯拉风生水起后，一时“软件定义汽车”的妖风四起，在大众成立软件开发独立部门之后，丰田也正式成立软件子公司-Woven Planet Holdings，专注于开发自动驾驶、新的汽车操作系统以及高清地图等软件业务。国内上汽等主机厂也纷纷成立自己的软件中心，例如上汽的零束，都想在这次变革中掌握软件开发的主动权。
传统开发模式为，整车厂提供需求，供应商负责实现软硬件，类似BOSCH、大陆等这些跨国500强，在这些零部件的软硬件开发上经验丰富，产品迭代了几十代，无论从成本还是稳定性，相比整车厂自己开发的软件可以说是碾压的存在，而且还有专利加持，整车厂转型软件可以说是举步维艰，就拿 ESP 车身稳定系统来说，日系的厂家开发出了同样的功能，但是由于专利限制，甚至连 ESP 的名字都不能叫，改名 VSC ，可想而知其在开发阶段为了规避专利风险，到底饶了多少弯路。这些对于要转型软件开发的整车厂也是一样的，行业壁垒不是那么容易破除。再有就是实实在在的高端软件人才吸引能力，汽车属于典型的重资产行业，要造车的话需要买地建厂买设备建产线，而当前火热的软件开发IT 行业，人的工资就是最大的投资成本，说白了，汽车行业软件从业人员的公司，和互联网无法站在同一竞技擂台上进行比对，所以整体上是缺少高端软件人才的，这样造成了当前整车厂软件开发的转型困境。
基于如上几点，整车厂已经发现软件开发不在是传统的单个工厂物料而已，很快就会成为自家公司的核心竞争力，所以开始下重力气建立软件研发团队，进行核心软件开发。尤其目前智能化、网联化和电动化的趋势下，使大家最大程度的站在了同一起跑线下，因此整车厂想从之前的“组装厂”模式开始研发和生产自己的软硬件，并自己进行产品的改进和价值创造。因此在这种趋势下，以前供应商全包的模式将逐渐弱化，而是与OEM合作开发的模式，比如供应商仅提供硬件，主机厂进行软件的开发。
首先需要承认整车厂想把握主动权并进行自身软硬件能力的提升是正确的，而且软件合作开发模式将成为以后的一种主流，但真正做好真的还任重道远，为啥呢？
跑在汽车上的软件，第一要义就是稳定可靠，而且在高震动，复杂电磁环境，大温差的前提条件下，能保证百万级的量产车不能出现严重软件bug，每辆车数十甚至上百的控制器，要保证亿数量级的产品稳定，这还是基本盘。可以看下由于软件bug造成的历史著名事件，丰田刹车门，手机电脑可以死机，汽车别说死机，就是一个小小的位反转，都有可能丧失生命，汽车电子软件工程本身是复杂度和高可靠性要求集合。
汽车电子软件开发发展到今天，已经形成了完整的行业规范流程和功能安全等级验证，可以参考部分法律执行，不仅要求结果正确，还要求程序正义。在这一行，可以说不仅要求开发出的软件满足所需功能和需求，以及功能安全网络安全要求，还要满足开发过程遵循 ASPICE ,有完整的过程文档记录和追溯，甚至会细化到开会评审的记录文档，如果有个别楞头，就是说我们软件很优秀，管你这个流程那个要求，放车上跑就完事了。对于这种，被使用的资质都没有更不用说在量产车上用了。所以现阶段汽车上跑的软件，从源头上就不存在个人小作坊开发，都是公司里正规军团队经历很长时间才能完成。
四、汽车总线基于SOA的需求将逐渐采用以太网为主干网，多种总线共存的状态
汽车上的总线技术包括：LIN、CAN、CAN FD、FlexRay、MOST及Ethernet。就目前汽车上的应用情况，成本低、可靠性高、应用普遍的有Lin、CAN通讯，CAN FD也是最近几年才逐渐得到应用，CAN FD是对传统CAN总线的一种扩展和过渡，其目的就是Make CAN Fast，首先其不会对原有的整车网络带来大的变更，具备很好的兼容性又具有可观的传输速率。在开发迁移量、时间成本、硬件成本等方面的考虑下，CAN FD在当前阶段是很好的过渡方案。
但随着汽车电子电器架构复杂度的提升尤其当前辅助驾驶系统、无人驾驶技术的快速发展，传统的LIN、CAN总线已不堪重负且无法满足未来高带宽的要求，例如无人驾驶技术涉及摄像头、激光雷达等传感器及不同控制器之间大量数据的采集、传输和处理。当同时考虑X-By-Wire应用场景和更高的带宽要求时，CAN FD可能也无法满足，因此对于线控应用场景，FlexRay是一种不错的方案，因FlexRay是专为车内局域网设计的一种具备故障容错的高速可确定性车载总线系统，采用了基于时间触发的机制且具有高带宽、容错性好等特点，在实时性、可靠性及灵活性方面都有很大的优势，非常适用于安全性要求较高的线控场合及带宽要求高的场合。但FlexRay的应用对OEM的能力要求相比CAN会提高很多，同时全部升级为FlexRay会带来开发迁移量、时间成本、硬件成本等方面的同步提升（所有节点必须升级为FlexRay节点）。此外，就我个人观点而言，FlexRay后续得到普遍应用的可能性不是很大，首先成本方面与车载以太网差不多而通讯速率又远低于它，而车载Ethernet在未来得到推广的可能性要比FlexRay高很多。需要注意的是CAN FD在市场推广实施还没有几年，第三代CAN总线-CAN XL也即将登场，CAN XL传输速率将达到10Mbit/s，可填补CAN FD和百兆车载以太网（100BASE-T1）之间的鸿沟，从这点也可以看出车载通讯的快速发展及对通讯带宽的越来越高的要求。
当然所有总线的应用都是分所在的域和场景的，例如对于安全要求很高的场合，采用了基于时间触发机制的FlexRay因实时性和确定性更高可能更合适，再比如在后续基于SOA的高带宽数据传输应用场景，车载以太网则更适合。而对于一些动力域控制器本来就可通过CAN满足需求的何必花精力和额外的成本去用其他总线技术取代。因此相比说要取代，我认为更应该是并存，每种总线技术都有其存在的价值，在满足要求的前提下，采用成本低、成熟的总线技术肯定是首选。
五、多核异构处理器应用将为主流
为什么需要多核处理器，我主要基于四点阐述下原因：
1、汽车电子电器架构和整车功能越来越复杂，需要计算能力更强大的硬件来支持越来越复杂的软件功能，随着ADAS、自动驾驶等应用场景的加入及未来域集中甚至中央计算机的E/E架构变更，多核系统的需求将更加明显。
2、并行计算的需求：例如某些功能的输出计算需要多个输入要素在相同时间片内执行并在同一时刻输入到该功能模块。
3、相同时间片内多个任务的串行计算需求：例如多个功能需要在相同的时间内被串行执行。
4、系统响应能力的需求：例如对于那些对时间要求特别高的中断处理需要单独在一个核上运行，而周期性任务则放到另外一个核上运行，从而提高整个系统的响应能力。
当然多核系统的软件开发集成相比单核，在项目时间、复杂度、成本以及给攻城狮带来的额外工作量都是成倍增加的。多核处理器的应用也会带来诸多挑战，例如满足ISO26262功能安全的挑战、合理分配各核计算负载、多核系统数据一致性挑战等等。
六、更加注重软件架构的设计
软件架构这部分，我们抛开一些闭源的诸如特斯拉的软件，来谈谈大家普遍接触的的Classic Autosar和Adaptive Autosar。我们整车上的控制器，分动力域的控制器，如发动机控制EMS、TCU等，还有信息娱乐域的控制器比如车机显示灯，不同控制器的实时性要求等方面是不一样的。例如发动机控制器ECU、或者整车控制器VCU实时性和功能安全要求要比与其他功能或信息娱乐性控制器高，动力域的基本基于Autosar经典平台开发，因其具有如下特点：
1、硬实时，可在us时间内完成事件的实时处理，硬实时任务必须满足最后期限的限制，以保证系统的可靠运行。 2、高功能安全等级，其可达到ASIL-D的安全等级。 3、对CPU、RAM或Flash等资源具有较低的占用率。 4、软件功能通常是固化不可动态变更的。 而信息娱乐性控制器，则正好与上相反，其一般会占用较大的硬件资源，且一般实时性要求相对低，因其一般运行在嵌入式PC上，如LINUX，而不是汽车级操作系统上，所以其即使出现故障也不会造成严重的安全事故。而ApdativeAutosar则是连接这两者的桥梁，其具有如下特点： 1、软实时，具有毫秒级内的最后期限，且偶尔错过最后期限也不会造成灾难性后果。 2、具有一定的功能安全要求，可达到ASIL-B或更高。 3、与经典平台不同的是，它更适用于多核动态操作系统的高资源环境，如QNX。
Adaptive Autosar与Classic Autosar相比，虽实时性要求有所降低，但在保证一定功能安全等级的基础上，大大提高了对高性能处理能力的支持，以支持智能互联应用功能的开发，因此C 将成为AdaptiveAutosar平台的主要开发语言。
Adaptive Autosar的出现并不是为了取代ClassicAutosar平台，而是针对不同的应用场景实现两者的共存和协作，Classic Autosar平台支持高安全性和高实时性的应用场景，因此对于深度嵌入式的软件功能需部署运行在经典平台上，而Adaptive Autosar则支持并行处理的需要高性能运算的功能则需要运行在Adaptive平台上。
当然在软件架构方面本来是多样的，采用哪种就看主机厂如何考量和能力如何了，多软件架构，诸如Autosar、Adaptive Autosar、ROS等将会耦合集成。
七、标准和流程方面
为了满足汽车软件开发高质量的标准，ASPICE 过程模型被建立，ASPICE是安全和保障的基础，楼主相信这是未来保证软件开发质量的一个重要方面，不管是供应商还是各大OEM都应逐渐应用起来。
ISO26262标准则在流程和方法论方面定义了系统开发中功能安全的影响，对于软件架构，功能安全是一个非常关键的因素，如何设计车内系统使其能符合功能安全标准要求是一个巨大挑战，特别是在日渐增加的应用复杂性以及产品上市时间的紧迫性的双重压力之下。电子系统面临的挑战是构建的系统需要能够防止危险故障的发生或至少在出现故障时能够有效地进行控制。功能安全标准已应用于车辆安全系统，如安全气囊或 ADAS。ISO26262是从IEC61508标准派生而来，针对道路乘用车车辆内的电气/电子系统。该标准应对架构、功能和程序方面的问题，包括汽车安全生命周期，以避免并控制系统错误以及随机硬件故障。ISO 26262指定了四个ASIL等级(A至D)以确定标准的必要要求以及用于避免不合理残余风险的安全措施，其中D表示最严格的安全等级，A表示最宽松的安全等级。通过考量任务数据中系统故障可能导致伤害的那部分(即出现概率)；驾驶员应付系统故障并避免伤害的能力(即可控性)；以及可控性操作失败会导致的人身后果(即严重程度) 这三点，进行车辆层面的危险分析和风险评估，确定适当的ASIL等级。
