这个时候抱着**“软件定义汽车”**思维的工程师跨步走来,看着他们好像要做软件了,实际他们第一件事还是尽可能的要折腾下硬件,就是在把尽可能多不同的总线合并(所有路都按照一个标准修建),另外尽可能多的合并控制器(哪有那么多山头,交通部全中国就一个),这样后面有个啥世博会,马拉松啥的,我可以根据需求统一变化,适应各种需求。
博世电子电器架构研究研究
这里还是要再专业点描述这个问题,在软件定义汽车思维下有三个重要的关注点
**硬件成本进一步降低:**相同功能需求下,减少 ECU(电子控制单元)数量,可以降低 ECU 物料成本,另一方面也进一步减少了整车线束使用量。Model S 线束约 3 公里长,而 Model 3 缩短了近 1 倍。
**硬件抽象:**此前的供应体系是供应商将「软件+零部件」打包卖给主机厂,软硬件的耦合很深,议价能力差,测试调试苦难。特斯拉的牛叉在于软件基本自己写,即便更换硬件供应商,也不会显著影响软件功能的部署。
**OTA升级:**在硬件抽象的基础上,特斯拉可以通过 OTA 的方式进行新功能的更新下放,以及对车辆状况进行良好监控,降低维修成本。整车软件开发变得更多样化,更简单。
一个最经典例子:特斯拉通过 OTA 解决制动距离过长的问题。彼时 Consumer Reports(消费者报告)发布的特斯拉 Model 3 测评中指出,这台车的 60mph-0 刹停距离并不理想,达到了 46.33 米,但是经过 OTA,Model 3 的刹车距离得到了显著提升。
刚才说了有三批工程师来解决这些问题,目前第二批工程师代表了主流的主机厂,而第三批工程师代表了Tesla等新兴的车企。主流主机厂看Tesla不眼馋嘛?家大业大干不过他?还真是。。。
阻碍帝国成长的是帝国本身,软件定义汽车本质就不是一个技术问题
表面上,车子都是整车厂造出来的,但这并不意味着车上的所有技术都是由整车厂研发的,供应商才是大部分技术的幕后功臣,而「整合」才是整车厂的重要任务。汽车工业百年发展,早已形成完备且复杂的供应商体系,比如我们常说的一级供应商、二级供应商、三级供应商。。。。
如此多供应商的加持,看起来更牛逼了。旧时代看着是一只军队,新时代里就变成了乌合之众。车企转型需要自身有足够强的研发能力,还得和供应商不断博弈,付出大量的人力物力财力,还需要经过一个比较长的磨合期,才能真正在量产车上落地。
**更重要的,欲练此功,必先自宫,主机厂们担心特斯拉的这种设计趋势会淘汰掉他们数十年来培育起来的零部件供应链。**谁能想到有一天,曾经让主机厂安逸发财的供应链成为阻碍其创新的绊脚石?
大众、丰田、上汽等传统整车厂,体量巨大。在电子电气架构上动刀子 , 如果不成功,谁来为负责?轻则影响公司未来几年产品的销量,重则事关生死。而且,难免会因此而触犯别人的利益,推行阻力很大。
特斯拉体量小得多,也没什么历史包袱,因此可以直接上手去做。而马斯克个人秉承的第一性原理的思维方式以及超强控制欲,多年以来,公司坚持创新自研、垂直整合,已经是这家公司的深刻烙印。特斯拉在电子电气和软件层面的优势,并不是偶然。
**传统车厂也在行动:**大众开发了自己的 MEB 纯电动平台,同时斥巨资成立软件中心,提升自己的软件能力,与此同时,大众设计了全新的 E3 电子架构,计划将 70 个 ECU 减少到 3 个域控制器。去年 5 月,通用汽车发布了新一代电子电气架构,支持整车 OTA。宝马也在全新一代产品(3 系、X5、X7)都已经可以支持整车 OTA,如果不是在电子架构层面做改变,这个特性是很难实现的。中国的头部 OEM 都在积极开发下一代的电子电气架构,并且在 2022 年左右实现新一代电子电气架构的平台化。
趣闻:量产过程,不是自动驾驶工程师不努力,而是臣妾做不到哈
如果你知道整车开发流程,一定知道“冻结”这个概念,关键接口,关键零部件在每个小迭代周期都会进行冻结,以维持各个块线的合作和同步推进,详细可见下面的回答。
没有OTA或者域控制器之前,智能驾驶功能必须要等到底盘性能完全冻结才能开始进行标定、调教和测试,虽然多数时候会分多个迭代过程,进行多个周期的调试,但不管哪个周期,智能驾驶功能永远是拍在最后的。一旦前面的某些开发出现了延期,在量产前最着急最痛苦的就是智能驾驶工程师,因为压缩的基本都是他们性能提升和测试的时间。
自动驾驶的研发周期理论上就不可能和整车研发周期契合!
无论生物成长还是汽车制造基本都一个道理:简单构件往往会优先产生并投入工作,以支持复杂构建的产生,骨架,心肺,往往都会优先形成机能并支持大脑器官的发育,后者的成熟周期往往是最长的。不同器官需要处理的任务维度不同,因此复杂度也不同
就像小宝宝,如果它脑袋在出了娘胎后就不成长(传统电气架构),那牛津大学也要在娘胎里读了。虽然骨架,肌肉,心肺都可以在出生前健全,但10个月时间脑子的核心功能是好不了的,他需要对接外部环境。但如果可以后天学习,那ok了,差不多时候我就可以从娘胎里出来了。
OTA或者域控制器的产生,为自动驾驶等功能释放了更多空间和时间,让其开发周期和测试周期得到必要的保障。
你以为结束了?软件定义汽车的工程师刚刚完成了第一步!
把硬件折腾清楚了,充其量就是车的硬件基本可以和一台电脑或者一部手机相比较了,可这些东西可以真正工作起来还缺个操作系统哈(什么android,Windows,Linux),那汽车的操作系统是什么?
请看第二篇
软件定义汽车(2)-软件中间件(Autosar为例)
已剪辑自: https://zhuanlan.zhihu.com/p/261291971
接前一篇文章:
殷玮:软件定义汽车(1)-整车电子电气架构EEA392 赞同 · 29 评论文章
工程师们把硬件折腾的差不多了,嗯,是不是可以开始应用软件快乐的开发了,还不是哈,我们都知道手机,电脑啥的在应用之下,硬件之上,还有一个东西叫操作系统,车辆里也有类似的东西。
操作系统,中间件,应用软件-各司其职分工不同
操作系统-我负责对硬件,提供线程创建等服务,其他我不管
中间件-我负责和不同操作系统对接,并给上面应用提供通讯,资源管理等服务,其他我不管
应用软件-嗯,剩下都我的事,我管功能,不同系统,不同硬件的事我不管。
中间件(middleware)是基础软件的一大类,在操作系统、网络和数据库之上,应用软件的下层,总的作用是为处于自己上层的应用软件提供运行与开发的环境,帮助用户灵活、高效地开发和集成复杂的应用软件。在不同的技术之间共享资源并管理计算资源和网络通信。
另外中间件的定位不是操作系统,而是一套软件框架,虽然包括了RTOS,MCAL,服务通信层等协议和服务。两者看着很接近,但没有多少竞争关系。
操作系统的话题,我们另外一篇文章再聊,今天关注软件定义汽车的话题中心-中间件。
什么是汽车软件中间件?
随着汽车应用要求的不断提高,软件总量也随之迅速增长,这导致了系统的复杂性和成本的剧增,为了提高软件的管理性、移植性、裁剪性和质量,需要定义一套架构( Architecture );方法学( Methodology )和应用接口( Application Interface )。从而实现标准的接口、高质量的无缝集成、高效的开发以及通过新的模型来管理复杂的系统。
目前在汽车控制领域有多种总线标准,各侧重点有所不同。尽管总线通信速度越来越高,但是还没有通信网络可以完全满足未来汽车的所有成本和性能要求,因此需要兼容多种总线和底层协议的通信协议和规范。
中间件的核心思想在于“统一标准、分散实现、集中配置”。统一标准才能给各个厂商提供一个通用的开放的平台;分散实现则要求软件系统层次化、模块化,并且降低应用与平台之间的耦合度;不同模块来自不同的厂商,它们之间存在复杂的相互联系,要想将其整合成一个完善的系统,必须要求将所有模块的配置信息以统一的格式集中管理起来,集中配置生成系统。
这个架构还需要具备如下功能:解决汽车功能的可用性和安全性需求;保持汽车电子系统一定的冗余;可以移植到不同汽车的不同平台上;实现标准的基本系统功能作为汽车供应商的标准软件模块;通过网络共享软件功能;集成多个开发商提供的软件模块;在产品生命期内更好地进行软件维护;更充分地利用硬件平台的处理能力;可实现汽车电子软件的更新和升级等。
汽车软件中间件有什么好处?
所有把标准统一后的服务的优势都大同小异,总结主要几点
- 跨配置,跨车型,跨平台,跨硬件适应
- 提高了效率,软件开发聚焦差异化
- 软件认证有标准可依
- 方便行业软件互换,降低进入门槛
- 更简单的集成已有工具链,支持从设计到代码全流程
对于Autosar,说实话,最有利的是OEM和基础软件公司,OEM可以标准化接口,自己做应用层或找软件公司开发应用,基础软件公司可以多卖软件。最不愿意的是tier1,因为增加了成本,还逐步可能沦为硬件生产商。但这个也不能说是autosar的锅,软件定义汽车下这个趋势的发展是必然的。
汽车软件中间件有什么缺点?
老实讲,这块大家讲的很少,都说这个很美好,但实际操作过程中,我觉得是软硬件一体设计上的阻碍。
值得注意的像Tesla这样的新兴企业并没有使用autosar这是为什么?所有平台性的软件,都有一个弊病,就是为了兼容一致性,会对软硬件协作的效率带来影响,autosar也不例外。
我感觉“Autosar就是汽车行业的塞班系统,看似很好,很标准,但是最终会被淘汰。就像当年的诺基亚一样,原因是最后会被一个软硬件集成度更好的iphone取代,iphone可不纠结能够给其他公司用自己的系统。
从商业和成本角度看
Autosar设计上已经有些落后,代码臃肿,对成本影响很大。打个比方,北美一个程序员一年的cost也就是15万美金,自己完成底层的开发就这个价,使用Autosar的工具链和代码臃肿带来的升级MCU开销远大于节省的这部分开发成本。细分Autosar的成本:
1.开发成本:首先需要购买autosar,本身就是成本,autosar包含的模块多,肯定要贵,但不一定所有的都会被用上。其次是人力投入,对于一个原来就有其他平台的新的第一个项目转换到autosar是增加人力的,对于新公司,购买autosar是降低人力的,很多模块不用自己开发了。对于建立平台以后的项目,实际差不多。
2.生产成本:首先是硬件成本,现在MCU越来越便宜,用不用autosar基本没区别,如果说存储空间特别小的MCU,比如防夹模块,本来也没要求autosar。其次是软件成本,这个才是问题,跟以前基础软件不同autosar现在收量产license费。
从技术角度看
关于autosar的应用,autosar之前定义的主要就是BCM、TCU、EMS、ESP等要求实时控制的ECU。不是针对娱乐系统,自动驾驶MPU的,当然这些控制器里也有MCU,可以用运行autosar的MCU。autosar现在最擅长的是16bit MCU以及不太复杂的32bitMCU。32bit以上的MCU,需要RTOS支持,比如自动驾驶软件。 车的中控也不可能基于autosar,也是因为没有一个强有力的RTOS, 在越来越强调security的软件开发中,AUTOSAR也没有进程隔离的概念。前景难料.
中间件的明星方案-AUTOSAR
所有中间件方案中,最著名的是AUTOSAR, 其是由各大整车厂商和零部件厂商开始着手联合制定软件的标准化接口。AUTOSAR(AUTomotive Open System ARchitecture)是由全球的主要汽车生产厂商、零部件供应商、软硬件和电子工业等企业(如BMW、BOSCH、Continental、DAIMLER、Ford、OPEL、PSA、TOYOTA、VW等)共同制定的汽车开放式系统架构标准。
2003年7月,由宝马、博世、大陆、戴姆勒-克莱斯勒、西门子VDO和大众联合成立AUTOSAR发展联盟,为汽车E/E架构建立了一种开放式的行业标准。
2003年11月,福特公司作为核心伙伴加入,12月标致雪铁龙和丰田汽车加入。接下来的11月通用汽车也作为核心伙伴加入。自从西门子VDO被大陆在2008年2月收购后,它就不再作为AUTOSAR的独立核心伙伴。
- 第一阶段(2004-2006):标准基本开发时期(版本1.0.2.0和2.1)
- 第二阶段(2007-2009):体系和方法相关方面扩展(版本3.0,3.1和4.0)
- 第三阶段(2010-2013):可维护性和可选择性的改进(版本3.2,4.1和4.2)
在2013年,AUTOSAR联盟进入一种持续改进模式,主要用来维持标准和提供所选择的改进,往后实际上,autosar更新就很少了,开始转向AUTOSAR-Adaptive。
AUTOSAR-Adaptive拯救AUTOSAR
对于用于实现典型动力总成和底盘功能的深度嵌入式系统,AUTOSAR经典平台仍将是首选。在低成本硬件上运行时,对安全性、实时性和确定性要求较高。同时,AUTOSAR为这些应用程序提供了一个经过良好验证的成熟软件平台,包括一个广泛使用的方法,它支持当今所有的协作模型。而为了支持客户应用程序的动态部署,并为需要高端计算能力的应用程序提供环境,AUTOSAR在2017年推出了第二个软件平台,即AUTOSAR Adaptive platform。这个想法是尽可能从其他领域(如消费电子产品)的发展中获益,同时仍然考虑汽车的特定要求,如功能安全。
Adaptive需要支持,未来E/E架构的两个关键特征是:
**1) 异构软件平台的集成,**当今汽车的网络架构可以聚集成不同的领域,用于信息娱乐和连接、底盘、动力系统等。虽然infotainment ECUs通常使用Linux、QNX或其他通用操作系统,但AUTOSAR Classic平台是深度嵌入式控制单元的标准。随着新的用例和对计算能力的深入嵌入式应用程序不断增长的需求,第三种ecu将出现,它具有不同的特性,必须集成到现有的E/E体系结构中。
2) 面向服务和基于信号的通信,传统的汽车通信仍然是基于ecu向其他ecu提供信号广播的思想。这种范式非常适合于有限大小的控制数据,这些数据必须循环地进行通信。先进的应用程序,如高自动化驾驶与更高的负载要求,例如交换对象列表检测到的一组传感器和以太网作为一个通信系统需要更复杂的协议。面向服务通信的概念是基于在通信系统上提供服务的应用程序和订阅此服务的其他应用程序。然后数据只发送给订阅服务器。
面向服务的通信与现有的基于信号的范式的结合是未来E/E体系结构的第二个关键方面,从这个角度来看,这是一个艰巨的挑战。
为了解决AUTOSAR僵化的问题,Adaptive希望可以找到一种中间过程平台
ADAPTIVE为承载这些功能的软件基础设施增加了新的需求。除了现有的需求(如功能安全和安全性),软件架构还必须支持硬件(如具有高端计算能力的硬件)、空中更新、与后端系统的通信或应用程序的动态部署。
AUTOSAR Adaptive扩展了AUTOSAR平台,以满足当前汽车自动驾驶、电气化和互联互通等趋势的需求。因此,它在许多方面改变了已建立的E/E开发过程。最重要的变化是,基于信号的通信被面向服务的设计所取代。c++取代了C语言作为自适应应用程序的编程语言,以及基于posix的操作系统(如Linux用于自适应电子控制单元)是进一步的突破性转变。
AUTOSAR Adaptive 组件封装了SOA软件底层的通讯细节(包括SOME/IP协议,IPC等),同时提供代理(Proxy)-骨架(Skeleton)模型,该模型以C 面向对象语言描述,方便上层应用开发人员调用标准服务接口(API)进行开发。Application Design Model是该模型另一种可配置的呈现,开发人员通过使用相应的配置工具对Application Design Model进行描述和配置,即可实现基于SOA服务架构的软件落地和部署。联合电子使用AUTOSAR Adaptive组件完成SOA服务架构软件的开发
可以看到,自适应Autosar又找到了延续自己生命的另外一个理由,提供了一种由现在信号导向的架构往SOA架构的标准。未来由于控制器数量大幅度降低, 类似特斯拉这样的车企多半是不理会自适应AutosarAdaptive
与此同时,更多的相关配套供应商也在加快与AUTOSAR自适应平台的对接。去年11月,Real-Time Innovations(RTI)宣布,AUTOSAR最新版本的自适应平台(版本18-10),已经具有数据分发服务(DDS)标准的完整网络绑定。这意味着汽车制造商现在可以使用DDS实现AUTOSAR自适应框架,并开发高度自动驾驶系统,如4级和5级。DDS允许AUTOSAR完全支持高度自动驾驶系统,并提供“量产级通信框架”,保证这些复杂系统所需的可靠性、可伸缩性和性能。比如,在AUTOSAR中完全指定了DDS之后,汽车行业现在可以使用RTI Connext和DDS开发高性能应用程序,比如传感器融合应用程序。
AUTOSAR版本18-10有助于解决OEM软件开发团队在支持不同价格区间车型时所面临的各种安全和连接性挑战。此外,允许开发人员“动态配置平台”,以支持每个车型平台的各种操作模式和硬件功能。
软件定义汽车过程中 中间件就讲到这里,以下是技术细节,可看可不看。可转战下一个内容
殷玮:软件定义汽车(3)-SOA架构209 赞同 · 19 评论文章
技术细节-AUTOSAR的分层设计
这一块是非常技术的部分了,如果不是非常想学就可以跳过了,讨论autosar的分层设计要从如下几个角度切入。架构,方法学,应用接口。详细了解的话可以看这个文件
架构层面: AUTOSAR定义一个软件分层架构以支持汽车电子系统的集成。其体系架构从上至下依次为应用层、运行环境层(RTE)、以及基础软件层(BSW)
接着再复杂一些,BSW再分为复杂驱动模块, 微控制器抽象层、ECU抽象层、系统服务层
(1)应用层。包括应用软件组件、传感器和执行器软件组件,都位于应用层。该层的软件组件通过RTE进行内部通讯和访问ECU资源。应用层的软件实现独立于微控制器、ECU。
(2)RTE层。RTE层为应用层提供通讯服务。RTE层的实现与ECU和具体应用相关,必须为每个ECU分别实现,AUTOSAR软件组件之间通信需要通过RTE。
(3)服务层。包含RTOS、通信与网络管理、内存管理、诊断服务、状态管理、程序监控等服务。它为应用和基础软件模块提供基本服务,包括:操作系统服务、汽车网络通讯和管理服务、存储服务、诊断服务和ECU状态管理。服务层的实现部分与微控制器、ECU和具体应用相关。
(4)ECU抽象层。ECU抽象层抽象出ECU结构,如外设与ECU的联接方式等.虽然该层与ECU平台相关,但是与微控制器是无关的。这种无关性是由微控制器抽象层来实现的。其中封装了微控制器层及外围设备的驱动,并对微控制器内外设的访问进行了统一,实现了软件应用层与硬件系统的分离
(5)微控制器的抽象层(microcontroller abstraction layer,MCAL)。位于基础软件的最底层,包含了访问微控制器的驱动(如I/O驱动、ADC驱动等),做到了上层软件与微控制器的分离,以便应用的后续的移植复用。微控制器的抽象层是实现不同硬件接口统一化的特殊层,通过微控制器的抽象层可将硬件封装起来,避免了高层软件直接与微控制器的寄存器打交道。MCAL提供消息机制,并以此将指令、响应和信息分离成不同的过程。微控制器抽象层包括微控制器相关的驱动,它负责管理微控制器的外部设备,并将微控制器的信号提供给基础软件的元件。
(6)复杂驱动层,由于其严格的时序为应用层通过RTE访问硬件提供支持。
再复杂一些
再再复杂一些
-------------接着我们从RTE层往上看-------------
运行时环境( RTE )是应用软件和基础软件通信的桥梁,无论通信发生在 ECU之间( 如通过CAN、LIN、FlexRay、MOST等网络) ,还是在ECU内部,RTE均通过提供一致的接口和服务来实现SWC之间的通信抽象,其最终实现会因ECU的不同而有所差异。一般情况下,每一层只能使用下一层的接口,并向上一层提供服务接口。
应用层中的功能由**各软件组件(SWC)**实现,组件中封装了部分或者全部汽车电子功能,包括对其具体功能的实现以及对应描述,如控制大灯,空调等部件的运作,但与汽车硬件系统没有连接。
在设计开发阶段中,软件组件通信层面引入了一个新的概念,虚拟功能总线VFB(Virtual Functional Bus),它是对AUTOSAR所有通信机制的抽象,利用VFB,开发工程师将软件组件的通信细节抽象,只需要通过AUTOSAR所定义的接口进行描述,即能够实现软件组件与其他组件以及硬件之间的通信,甚至ECU内部或者是与其他ECU之间的数据传输。
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Go语言工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Go语言全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Golang知识点,真正体系化!
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新
如果你觉得这些内容对你有帮助,可以添加V获取:vip1024b (备注Go)
一个人可以走的很快,但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎扫码加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
19)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Golang知识点,真正体系化!
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新
如果你觉得这些内容对你有帮助,可以添加V获取:vip1024b (备注Go)
[外链图片转存中…(img-x9d32P0E-1713080357420)]
一个人可以走的很快,但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎扫码加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!