深度解读汽车域控制器

a21890f355439d617e9b543a2d501316.png


1.

什么是域控制器

过去十多年的汽车智能化和信息化发展产生了一个显著结果就是ECU芯片使用量越来越多。从传统的引擎控制系统、安全气囊、防抱死系统、电动助力转向、车身电子稳定系统;再到智能仪表、娱乐影音系统、辅助驾驶系统;还有电动汽车上的电驱控制、电池管理系统、车载充电系统,以及蓬勃发展的车载网关、T-BOX和自动驾驶系统等等。

传统的汽车电子电气架构都是分布式的(如下图2-1),汽车里的各个ECU都是通过CAN和LIN总线连接在一起,现代汽车里的ECU总数已经迅速增加到了几十个甚至上百个之多,整个系统复杂度越来越大,几近上限。在今天软件定义汽车和汽车智能化、网联化的发展趋势下,这种基于ECU的分布式EEA也日益暴露诸多问题和挑战。

ff84fd0f34674d713d82497b2e3605ec.png
图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。

0ea26eb0a40451a9dfce2736e6a02236.png

图2-2 域集中式EE架构

2.

 域控制器市场概述

2018年,基于德尔福提供的域控制器技术,奥地利TTTech公司开发的zFAS控制器率先应用在奥迪A8当中。伟世通公司则推出了SmartCore域控制器,集成信息娱乐、仪表板、信息显示、HUD、ADAS等功能。这些产品开创了商用功能域控制器产品之先河,全球各大Tier 1供应商纷纷跟进,整个域控制器市场逐渐发展起来。

在国内市场,华为、德赛西威、航盛电子、东软等企业也推出了DCU解决方案,并得到了国内车企的采用。比如,2020年小鹏汽车推出的智能轿跑P7就采用了德赛西威基于英伟达Xavier打造的自动驾驶域控制器产品——IPU03。

当前,整个业界对DCU市场都有非常乐观的预期。据佐思产研的预测,2025年全球汽车DCU(座舱+自动驾驶)出货量将超过1400万套,2019-2025期间年平均增长高达50.7%。

e8961b5eb528da81e7b979a83d312e7b.png
图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(安波福)等。中国本土企业主要有德赛西威、航盛和东软睿驰等。

厂商芯片平台座舱域控制器名称操作系统/Hypervisor客户
伟世通高通SmartCoreAndroid,Linux吉利汽车、戴姆勒奔驰、东风、广汽
大陆高通/瑞萨集成式车身电子平台IIPQNX/PikeOS
博世高通AI Car ComputerAGL通用
Aptiv英特尔ICCLinux/ARCN长城、奥迪、沃尔沃
德赛西威高通820A
TI Jacinto6
智能座舱域控制器
理想汽车
东软睿驰英特尔C4-A1fusLinux/ARCN

表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自动泊车功能,目前车型渗透率较低,未来提升空间较大。

cf96ee09863bec9f093b4b23267df9fb.png
图2-4 中国ADAS功能市场渗透率预测

ADAS域控制器正在从过去的分布式系统架构演变到域集中式架构。过去一套ADAS系统,要有好几个独立的ECU才能实现,比如车道偏移和交通识别ECU、前向碰撞预警ECU、泊车辅助ECU等。现在有了功能强大的集中式ADAS域控制器后,一个域控制器就实现了所有功能。系统的软硬件复杂度大大降低,可靠性也得到了提高。

目前业内提供ADAS域控芯片平台的有NVIDIA、华为、瑞萨、NXP、TI、Mobileye,以及国内本土的地平线和黑芝麻等多个方案。下表2-2总结了全球主要ADAS域控制器厂商及其客户和伙伴信息。

厂商

ADAS域
控制器名称
计算芯片平台自动驾驶等级功能安全操作系统客户和量产、SOP计划
伟世通DriveCore支持NVIDIA、高通和NXP的处理器架构L2-L4ASIL-DAutoSAR CP,Auto AP,Linux等广汽,以及欧洲2家主机厂,计划2022年SOP
大陆ADCUNVIDIA DRIVE
Xavier
L3/L4ASIL-DAutoSAR Adaptive平台与NVIDIA合作的L3级别自动驾驶域控制器平台
车载服务器
(ICAS1)
NVIDIAL2ASIL-C/D大众MEB平台ID.3系列电动汽车

博世DASy 1.0NVIDIAL2/L2+ASIL-C/DAutoSAR CP,AutoSAR AP已于2019年SOP,支持HWP/TJA等L2+级别的功能
DASy 2.0NVIDIA DRIVE XavierL3/L4ASIL-DAutoSAR AP,Linux2022年SOP
TTTechzFAS/iECUNVIDIA TX2/Xavier///奥迪、上汽
Aptiv中央传感定位和规划(CSLP)平台Intel Mobileye////
Veoneer宙斯Zeus
Super Computer
NVIDIA Xavier
///
采埃孚中央控制器ProAINVIDIA Xavier///跟百度Apollo合作,客户是奇瑞
麦格纳MAX4////宝马
环宇智行TITANNVIDIA Xavier////
布谷鸟Auto WheelNXP///合作伙伴包括NXP、Renesas、Sony等
知行科技iMo DCU中央控制器TI Jacinto/NXP///众泰
经纬恒润ADAS Domain ControllerNXP////
东软睿驰ADAS DCUXilinx///乘用车和商用车主机厂
德赛西威自动驾驶平台NVIDIA Xavier///小鹏汽车

表2-2 全球主要ADAS域控制器厂商信息

3.

域控制器发展趋势

域控制器的兴起对传统的汽车MCU厂商造成了极大的挑战,“因为MCU使用量将大大减少,传统的MCU产品其演进路线将不复存在”。

在分布式ECU时代,计算和控制的核心是MCU芯片,传输的基础核心是基于传统的CAN、LIN和FlexRay等低速总线。但在域控制器时代,高性能、高集成度的异构SoC芯片作为域的主控处理器,将成为域控制器的计算与控制的核心芯片。而汽车TSN(Time-Sensitive Network)以太网因为具有高带宽、实时和可靠的数据通信能力等特点,必将成为整车通信的核心基础设施,尤其是域主控处理器之间的通信主干网。

下面我们来简单分析一下域控制器以及核心的主控处理器的一些关键技术和趋势。

3.1 高性能

总的来说,对算力的需求提升一直是域控制器核心芯片发展的主要推动力。一方面原本由多个ECU完成的功能,现在需要依靠单一的域主控处理器来完成,并且还需要管理和控制所连接的各种传感器与执行器等。比如:底盘、动力传动系统和车身舒适电子系统的域主控处理器,其算力需求大约在10000DMIPS-15000DMIPS左右。

641e5a31bd3faa7f2b4ee1df76bd4198.png
图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等也是常见的提高处理器安全特性的设计措施。

40ee446c16f1a6a50d4d2d976c1a8c82.png
图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能确保所接收到的数据的真实性,防止攻击者绕过相关的安全接口,入侵车载网络。

基于硬件的安全模块主要解决两个问题:

  1. 密钥泄漏问题:如果密钥存储在应用程序的代码或数据中,很容易被泄漏。所以有必要增加一个硬件模块,专门存储密钥。

  2. Crypto算法加速:通过内核来直接进行加密或解密运算会占用大量CPU算力资源。因此,有必要通过硬件模块来进行加密解密算法的加速。

SHE(Secure Hardware Extension)标准是由奥迪和宝马公司合作制定的、针对硬件安全模块HSM的规范,它主要包括密码模块的硬件、硬件软件接口。这个规范已被广泛接受,很多针对汽车行业的微处理器都支持这个规范。

3.8 面向服务的软件架构SOA

ECU原先运行的软件大多数是按照Classic AutoSAR规范开发的软件系统,其中的应用软件一般都是静态调度(Static Scheduling)模式的,也即在系统运行时,程序中不同功能的函数按照事先定义好的排序文件依次调用、逐个运行。静态调度的优点是资源分配问题都是事先安排好的,车辆量产后就不会再改变,每个功能对应的函数代码具体运行时间也被提前锁定,是确定性的。因此这种设计对于汽车上很多对功能安全要求苛刻的场景是非常适合的。比如:决定安全气囊是否打开的功能函数就是固定地每隔几毫秒运行一次,以便紧急情况下可以及时打开。

承载计算和控制的底层硬件从分散的多个ECU集中到多核、异构的高性能域主控处理器后,相应的软件也会从分散向集中、从简单向复杂、从静态向动态进化。下图2-7显示了以后汽车域控制器上的典型软件架构:

b6e8a52f7fa65ed4d9c8fe70ca3daa24.png
图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的思路拆分成一个一个小的服务,但是这些服务在部署上其实是集中式的。鉴于这种物理部署上的“集中”与运行时的“分布式”并存的特点,因此我们可以通过一系列技术手段来优化服务与服务之间的通信延迟(比如:通过共享内存技术)。这是车载分布式系统与互联网强调高并发特性的分布式系统之间另一个显著的差别。

4.

小结

域集中式EE架构会是未来相当长一段时间占主要地位的汽车EE架构,域控制器作为域集中式EE架构的核心,会在整个汽车产业链中占据越来越重要的地位。其相应的芯片和硬件方案、操作系统和算法等将会成为整个产业链各上下游厂家的争夺焦点。

合作联系方式:18515441838,标注“合作”。

欢迎加入智能交通群!标注”加群“。

85d6e0564f764dabc8407af5a4d19695.png

  • 18
    点赞
  • 175
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
 Spring3.0是Spring在积蓄了3年之久后,隆重推出的一个重大升级版本,进一步加强了Spring作为Java领域第一开源平台的翘楚地位。   Spring3.0引入了众多Java开发者翘首以盼的新功能和新特性,如OXM、校验及格式化框架、REST风格的Web编程模型等。这些新功能实用性强、易用性高,可大幅降低Java应用,特别是JavaWeb应用开发的难度,同时有效提升应用开发的优雅性。   《Spring3.x企业应用开发实战》是在《精通Spring2.x——企业应用开发详解》的基础上,经过历时一年的重大调整改版而成的,本书延续了上一版本追求深度,注重原理,不停留在技术表面的写作风格,力求使读者在熟练使用Spring的各项功能的同时,还能透彻理解Spring的内部实现,真正做到知其然知其所以然。此外,本书重点突出了“实战性”的主题,力求使全书“从实际项目中来,到实际项目中去”。 目录 第1篇 概述 第1章 Spring概述 1.1 认识Spring 1.2 关于SpringSource 1.3 Spring带给我们什么 1.4 Spring体系结构 1.5 Spring 3.0的新功能 1.5.1 核心API更新到Java 5. 1.5.2 Spring表达式语言 1.5.3 可通过Java类提供IoC配置信息 1.5.4 通用类型转换系统和属性格式化系统 1.5.5 数据访问层新增OXM功能 1.5.6 Web层的增强 1.5.7 其他 1.6 Spring对Java版本的要求 1.7 如何获取Spring 1.8 小结 第2章 快速入门 2.1 实例功能概述 2.1.1 比Hello World更适用的实例 2.1.2 实例功能简介 2.2 环境准备 2.2.1 创建库表 2.2.2 建立工程 2.2.3 类包及Spring配置文件规划 2.3 持久层 2.3.1 建立领域对象 2.3.2 UserDao 2.3.3 LoginLogDao 2.3.4 在Spring中装配DAO 2.4 业务层 2.4.1 UserService 2.4.2 在Spring中装配Service 2.4.3 单元测试 2.5 展现层 2.5.1 配置Spring MVC框架 2.5.2 处理登录请求 2.5.3 JSP视图页面 2.6 运行Web应用 2.7 小结 第2篇 IoC和AOP 第3章 IoC容器概述 3.1 IoC概述 3.1.1 通过实例理解IoC的概念 3.1.2 IoC的类型 3.1.3 通过容器完成依赖关系的注入 3.2 相关Java基础知识 3.2.1 简单实例 3.2.2 类装载器ClassLoader 3.2.3 Java反射机制 3.3 资源访问利器 3.3.1 资源抽象接口 3.3.2 资源加载 3.4 BeanFactory和ApplicationContext 3.4.1 BeanFactory介绍 3.4.2 ApplicationContext介绍 3.4.3 父子容器 3.5 Bean的生命周期 3.5.1 BeanFactory中Bean的生命周期 3.5.2 ApplicationContext中Bean的生命周期 3.6 小结 第4章 在IoC容器中装配Bean 4.1 Spring配置概述 4.1.1 Spring容器高层视图 4.1.2 基于XML的配置 4.2 Bean基本配置 4.2.1 装配一个Bean 4.2.2 Bean的命名 4.3 依赖注入 4.3.1 属性注入 4.3.2 构造函数注入 4.3.3 工厂方法注入 4.3.4 选择注入方式的考量 4.4 注入参数详解 4.4.1 字面值 4.4.2 引用其他Bean 4.4.3 内部Bean 4.4.4 null值 4.4.5 级联属性 4.4.6 集合类型属性 4.4.7 简化配置方式 4.4.8 自动装配 4.5 方法注入 4.5.1 lookup方法注入 4.5.2 方法替换 4.6 <bean>之间的关系 4.6.1 继承 4.6.2 依赖 4.6.3 引用 4.7 整合多个配置文件 4.8 Bean作用域 4.8.1 singleton作用域 4.8.2 prototype作用域 4.8.3 Web应用环境相关的Bean作用域 4.8.4 作用域依赖问题 4.9 FactoryBean 4.10 基于注解的配置 4.10.1 使用注解定义Bean 4.10.2 使用注解配置信息启动Spring容器 4.10.3 自动装配Bean 4.10.4 Bean作用范围及生命过程方法 4.11 基于Java类的配置 4.11.1 使用Java类提供Bean定义信息 4.11.2 使用基于Java类的配置信息启动Spring容器 4.12 不同配置方式比较 4.13 小结 第5章 Spring容器高级主题 5.1 Spring容器技术内幕 5.1.1 内部工作机制 5.1.2 BeanDefinition 5.1.3 InstantiationStrategy 5.1.4 BeanWrapper 5.2 属性编辑器 5.2.1 JavaBean的编辑器 5.2.2 Spring默认属性编辑器 5.2.3 自定义属性编辑器 5.3 使用外部属性文件 5.3.1 使用外部属性文件 5.3.2 使用加密的属性文件 5.3.3 属性文件自身的引用 5.4 引用Bean的属性值 5.5 国际化信息 5.5.1 基础知识 5.5.2 MessageSource 5.5.3 容器级的国际化信息资源 5.6 容器事件 5.6.1 Spring事件类结构 5.6.2 解构Spring事件体系的具体实现 5.6.3 一个实例 5.7 小结 第6章 Spring AOP基础 6.1 AOP概述 6.1.1 AOP到底是什么 6.1.2 AOP术语 6.1.3 AOP的实现者 6.2 基础知识 6.2.1 带有横切逻辑的实例 6.2.2 JDK动态代理 6.2.3 CGLib动态代理 6.2.4 AOP联盟 6.2.5 代理知识小结 6.3 创建增强类 6.3.1 增强类型 6.3.2 前置增强 6.3.3 后置增强 6.3.4 环绕增强 6.3.5 异常抛出增强 6.3.6 引介增强 6.4 创建切面 6.4.1 切点类型 6.4.2 切面类型 6.4.3 静态普通方法名匹配切面 6.4.4 静态正则表达式方法匹配切面 6.4.5 动态切面 6.4.6 流程切面 6.4.7 复合切点切面 6.4.8 引介切面 6.5 自动创建代理 6.5.1 实现类介绍 6.5.2 BeanNameAutoProxyCreator 6.5.3 DefaultAdvisorAutoProxyCreator 6.6 小结 第7章 基于@AspectJ和Schema的AOP 7.1 Spring对AOP的支持 7.2 JDK 5.0注解知识快速进阶 7.2.1 了解注解 7.2.2 一个简单的注解类 7.2.3 使用注解 7.2.4 访问注解 7.3 着手使用@AspectJ 7.3.1 使用前的准备 7.3.2 一个简单的例子 7.3.3 如何通过配置使用@AspectJ切面 7.4 @AspectJ语法基础 7.4.1 切点表达式函数 7.4.2 在函数入参中使用通配符 7.4.3 逻辑运算符 7.4.4 不同增强类型 7.4.5 引介增强用法 7.5 切点函数详解 7.5.1 @annotation() 7.5.2 execution() 7.5.3 args()和@args() 7.5.4 within() 7.5.5 @within()和@target() 7.5.6 target()的this() 7.6 @AspectJ进阶 7.6.1 切点复合运算 7.6.2 命名切点 7.6.3 增强织入的顺序 7.6.4 访问连接点信息 7.6.5 绑定连接点方法入参 7.6.6 绑定代理对象 7.6.7 绑定类注解对象 7.6.8 绑定返回值 7.6.9 绑定抛出的异常 7.7 基于Schema配置切面 7.7.1 一个简单切面的配置 7.7.2 配置命名切点 7.7.3 各种增强类型的配置 7.7.4 绑定连接点信息 7.7.5 Advisor配置 7.8 混合切面类型 7.8.1 混合使用各种切面类型 7.8.2 各种切面类型总结 7.9 JVM Class文件字节码转换基础知识 7.9.1 java.lang.instrument包的工作原理 7.9.2 如何向JVM中注册转换器 7.9.3 使用JVM启动参数注册转换器的问题 7.10 使用LTW织入切面 7.10.1 Spring的LoadTimeWeaver 7.10.2 使用LTW织入一个切面 7.10.3 在Tomcat下的配置 7.10.4 在其他Web应用服务器下的配置 7.11 小结 第3篇 数据访问 第8章 Spring对DAO的支持 8.1 Spring的DAO理念 8.2 统一的异常体系 8.2.1 Spring的DAO异常体系 8.2.2 JDBC的异常转换器 8.2.3 其他持久技术的异常转换器 8.3 统一数据访问模板 8.3.1 使用模板和回调机制 8.3.2 Spring为不同持久化技术所提供的模板类 8.4 数据源 8.4.1 配置一个数据源 8.4.2 获取JNDI数据源 8.4.3 Spring的数据源实现类 8.5 小结 第9章 Spring的事务管理 9.1 数据库事务基础知识 9.1.1 何为数据库事务 9.1.2 数据并发的问题 9.1.3 数据库锁机制 9.1.4 事务隔离级别 9.1.5 JDBC对事务支持 9.2 ThreadLocal基础知识 9.2.1 ThreadLocal是什么 9.2.2 ThreadLocal的接口方法 9.2.3 一个TheadLocal实例 9.2.4 与Thread同步机制的比较 9.2.5 Spring使用ThreadLocal解决线程安全问题 9.3 Spring对事务管理的支持 9.3.1 事务管理关键抽象 9.3.2 Spring的事务管理器实现类 9.3.3 事务同步管理器 9.3.4 事务传播行为 9.4 编程式的事务管理 9.5 使用XML配置声明式事务 9.5.1 一个将被实施事务增强的服务接口 9.5.2 使用原始的 TransactionProxyFactoryBean 9.5.3 基于tx/aop命名空间的配置 9.6 使用注解配置声明式事务 9.6.1 使用@Transactional注解 9.6.2 通过AspectJ LTW引入事务切面 9.7 集成特定的应用服务器 9.7.1 BEA WebLogic 9.7.2 BEA WebLogic 9.8 小结 第10章 Spring的事务管理难点剖析 10.1 DAO和事务管理的牵绊 10.1.1 JDBC访问数据库 10.1.2 Hibernate访问数据库 10.2 应用分层的迷惑 10.3 事务方法嵌套调用的迷茫 10.3.1 Spring事务传播机制回顾 10.3.2 相互嵌套的服务方法 10.4 多线程的困惑 10.4.1 Spring通过单实例化Bean简化多线程问题 10.4.2 启动独立线程调用事务方法 10.5 联合军种作战的混乱 10.5.1 Spring事务管理器的应对 10.5.2 Hibernate+Spring JDBC混合框架的事务管理 10.6 特殊方法成漏网之鱼 10.6.1 哪些方法不能实施Spring AOP事务 10.6.2 事务增强遗漏实例 10.7 数据连接泄漏 10.7.1 底层连接资源的访问问题 10.7.2 Spring JDBC数据连接泄漏 10.7.3 通过DataSourceUtils获取数据连接 10.7.4 通过DataSourceUtils获取数据连接 10.7.5 JdbcTemplate如何做到对连接泄漏的免疫 10.7.6 使用TransactionAwareDataSourceProxy 10.7.7 其他数据访问技术的等价类 10.8 小结 第11章 使用Spring JDBC访问数据库 11.1 使用Spring JDBC 11.1.1 JDBCTemplate小试牛刀 11.1.2 在DAO中使用JDBCTemplate 11.2 基本的数据操作 11.2.1 更改数据 11.2.2 返回数据库的表自增主键值 11.2.3 批量更改数据 11.2.4 查询数据 11.2.5 查询单值数据 11.2.6 调用存储过程 11.3 BLOB/CLOB类型数据的操作 11.3.1 如何获取本地数据连接 11.3.2 相关的操作接口 11.3.3 插入Lob类型的数据 11.3.4 以块数据方式读取Lob数据 11.3.5 以流数据方式读取Lob数据 11.4 自增键和行集 11.4.1 自增键的使用 11.4.2 如何规划主键方案 11.4.3 以行集返回数据 11.5 其他类型的JDBCTemplate 11.5.1 NamedParameterJDBCTemplate 11.5.2 SimpleJDBCTemplate 11.6 以OO方式访问数据库 11.6.1 使用MappingSqlQuery查询数据 11.6.2 使用SqlUpdate更新数据 11.6.3 使用StoredProcedure执行存储过程 11.6.4 SqlFunction类 11.7 小结 第12章 整合其他ORM框架 12.1 Spring整合ORM技术 12.2 在Spring中使用Hibernate 12.2.1 配置SessionFactory 12.2.2 使用HibernateTemplate 12.2.3 处理LOB类型数据 12.2.4 添加Hibernate事件监听器 12.2.5 使用原生Hibernate API 12.2.6 使用注解配置 12.2.7 事务处理 12.2.8 延迟加载的问题 12.3 在Spring中使用myBatis 12.3.1 配置SqlMapClient 12.3.2 在Spring配置myBatis 12.3.3 编写myBatis的DAO 12.5 DAO层设计 12.5.1 DAO基类的设计 12.5.2 查询接口方法的设计 12.5.3 分页查询接口设计 12.6 小结 第4篇 业务层及Web层技术 第13章 任务调度和异步执行器 13.1 任务调度概述 13.2 Quartz快速进阶 13.2.1 Quartz基础结构 13.2.2 使用SimpleTrigger 13.2.3 使用CronTrigger 13.2.4 使用Calendar 13.2.5 任务调度信息存储 13.3 在Spring中使用Quartz 13.3.1 创建JobDetail 13.3.2 创建Trigger 13.3.3 创建Scheduler 13.4 Spring中使用JDK Timer 13.4.1 Timer和TimerTask 13.4.2 Spring对JDK Timer的支持 13.5 Spring对JDK 5.0 Executor的支持 13.5.1 了解JDK 5.0的Executor 13.5.2 Spring对Executor所提供的抽象 13.6 实际应用中的任务调度 13.6.1 如何产生任务 13.6.2 任务调度对应用程序集群的影响 13.6.3 任务调度云 13.6.4 Web应用程序中调度器的启动和关闭问题 13.7 小结 第14章 使用OXM进行对象XML映射 14.1 认识XML解析技术 14.1.1 什么是XML 14.1.2 XML的处理技术 14.2 XML处理利器:XStream 14.2.1 XStream概述 14.2.2 快速入门 14.2.3 使用XStream别名 14.2.4 XStream转换器 14.2.5 XStream注解 14.2.6 流化对象 14.2.7 持久化API 14.2.8 额外功能:处理JSON 14.3 其他常见O/X Mapping开源项目 14.3.1 JAXB 14.3.2 XMLBeans 14.3.3 Castor 14.3.4 JiBX 14.3.5 总结比较 14.4 与Spring OXM整合 14.4.1 Spring OXM概述 14.4.2 整合OXM实现者 14.4.3 如何在Spring中进行配置 14.4.4 Spring OXM 简单实例 14.5 小结 第15章 Spring MVC 15.1 Spring MVC概述 15.1.1 体系结构 15.1.2 配置DispatcherServlet 15.1.3 一个简单的实例 15.2 注解驱动的控制器 15.2.1 使用@RequestMapping映射请求 15.2.2 请求处理方法签名概述 15.2.3 处理方法签名详细说明 15.2.4 使用HttpMessageConverter<T> 15.2.5 处理模型数据 15.3 处理方法的数据绑定 15.3.1 数据绑定流程剖析 15.3.2 数据转换 15.3.3 数据格式化 15.3.4 数据校验 15.4 视图和视图解析器 15.4.1 认识视图 15.4.2 认识视图解析器 15.4.3 JSP和JSTL 15.4.4 模板视图 15.4.5 Excel 15.4.6 PDF 15.4.7 输出XML 15.4.8 输出JSON 15.4.9 使用XmlViewResolver 15.4.10 使用ResourceBundle ViewResolver 15.4.11 混合使用多种视图技术 15.5 本地化解析 15.5.1 本地化概述 15.5.2 使用CookieLocaleResolver 15.5.3 使用SessionLocaleResolver 15.5.4 使用LocaleChangeInterceptor 15.6 文件上传 15.6.1 配置MultipartResolver 15.6.2 编写控制器和文件上传表单页面 15.7 杂项 15.7.1 静态资源处理 15.7.2 装配拦截器 15.7.3 异常处理 15.8 小结 第5篇 测试及实战 第16章 实战型单元测试 16.1 单元测试概述 16.1.1 为什么需要单元测试 16.1.2 单元测试之误解 16.1.3 单元测试之困境 16.1.4 单元测试基本概念 16.2 JUnit 4快速进阶 16.2.1 JUnit 4概述 16.2.2 JUnit 4生命周期 16.2.3 使用JUnit 16.3 模拟利器Mockito 16.3.1 模拟测试概述 16.3.2 创建Mock对象 16.3.3 设定Mock对象的期望行为及返回值 16.3.4 验证交互行为 16.4 测试整合之王Unitils 16.4.1 Unitils概述 16.4.2 集成Spring 16.4.3 集成Hibernate 16.4.4 集成Dbunit 16.4.5 自定义扩展模块 16.5 使用Unitils测试DAO层 16.5.1 数据库测试的难点 16.5.2 扩展Dbunit用Excel准备数据 16.5.3 测试实战 16.6 使用unitils测试Service层 16.7 测试Web层 16.7.1 对LoginController进行单元测试 16.7.2 使用Spring Servlet API模拟对象 16.7.3 使用Spring RestTemplate测试 16.7.4 使用Selenium测试 16.8 小结 第17章 实战案例开发 17.1 论坛案例概述 17.1.1 论坛整体功能结构 17.1.2 论坛用例描述 17.1.3 主要功能流程描述 17.2 系统设计 17.2.1 技术框架选择 17.2.2 Web目录结构及类包结构规划 17.2.3 单元测试类包结构规划 17.2.4 系统的结构图 17.2.5 PO的类设计 17.2.6 持久层设计 17.2.7 服务层设计 17.2.8 Web层设计 17.2.9 数据库设计 17.3 开发前的准备 17.4 持久层开发 17.4.1 PO类 17.4.2 DAO基类 17.4.3 通过扩展基类所定义DAO类 17.4.4 DAO Bean的装配 17.4.5 使用Hibernate二级缓存 17.5 对持久层进行测试 17.5.1 配置Unitils测试环境 17.5.2 准备测试数据库及测试数据 17.5.3 编写DAO测试基类 17.5.4 编写BoardDao测试用例 17.6 服务层开发 17.6.1 UserService的开发 17.6.2 ForumService的开发 17.6.3 服务类Bean的装配 17.7 对服务层进行测试 17.7.1 编写Service测试基类 17.7.2 编写ForumService测试用例 17.8 Web层开发 17.8.1 BaseController的基类 17.8.2 用户登录和注销 17.8.3 用户注册 17.8.4 论坛管理 17.8.5 论坛普通功能 17.8.6 分页显示论坛版块的主题帖子 17.8.7 web.xml配置 17.8.8 Spring MVC配置 17.9 对Web层进行测试 17.9.1 编写Web测试基类 17.9.2 编写ForumManageController测试用例 17.10 部署和运行应用 17.11 小结 以下内容详见本书配书光盘: 附录A JavaMail发送邮件 附录B 在Spring中开发Web Service

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值