当软件定义汽车成为趋势,未来汽车是否可以理解为四个轮子上的超级计算机?

文章目录

  • 浅谈汽车软件行业
  • 汽车软件的现状和发展方向
    • 本文首发于EE汽车荟,在微信公众号搜索“EE汽车荟”可以查看。
    • 简介:本文就目前比较热的“汽车软件”话题,做一些讨论。也试图回答大家比较关心的三个问题。内容主要有三方面:1)传统汽车是否有软件,为什么传统汽车业看起来像是被动地发展汽车软件)现在新能源车普遍拥有的语音控制系统,自动泊车,拥堵跟随系统,是否可以认为是革命性的汽车软件)汽车软件的前景如何哪些瓶颈技术以及创新/li>
  • 如何理解「软件定义汽车」/li>
    • 传统汽车到底出现了什么问题/li>
    • **软件定义汽车,说直白点,就是把车做成手机**
    • **1、为什么软件定义汽车*
    • 2、软件如何定义汽车/li>
    • **3、怎么实现软件定义汽车*
  • 软件定义汽车(1)-整车电子电气架构EEA
    • 阻碍帝国成长的是帝国本身,软件定义汽车本质就不是一个技术问题
    • 趣闻:量产过程,不是自动驾驶工程师不努力,而是臣妾做不到哈
    • 自动驾驶的研发周期理论上就不可能和整车研发周期契合!
    • **你以为结束了件定义汽车的工程师刚刚完成了第一步!**
  • 软件定义汽车(2)-软件中间件(Autosar为例)
    • 操作系统,中间件,应用软件-各司其职分工不同
    • **什么是汽车软件中间件*
    • 汽车软件中间件有什么好处/li>
    • 汽车软件中间件有什么缺点/li>
    • 中间件的明星方案-AUTOSAR
    • AUTOSAR-Adaptive拯救AUTOSAR
    • 技术细节-AUTOSAR的分层设计
    • 技术细节-AUTOSAR ADAPTIVE架构介绍
  • 软件定义汽车(3)-SOA架构
    • 整车现在采用了什么机制/li>
    • 为啥要用SOA呢了SOA有什么好处/li>
    • SOA架构下整车采用了什么机制重境修为SOC(Service Oriented Communication) 基于服务的通讯
    • SOA架构下整车采用了什么机制重境修为SORS(Service-Oriented Reuse-shared Design)基于服务的复用共享式设计
    • SOA架构的开发思想梳理
    • **SOC(Service Oriented Communication) 设计细节**
    • **SORS(Service-Oriented Reuse-shared Design) 设计细节**
  • 软件定义汽车(4)-OTA升级
    • FOTA和SOTA的区别
    • OTA升级的意义
    • OTA升级流程
    • 客户导向的OTA设计原则
    • OTA短期体验问题
    • OTA长期体验问题
    • 总结
  • 汽车OTA哪家强/li>
    • **OTA赛道入场券**
    • 小鹏汽车
    • 蔚来
    • 理想
    • 特斯拉
    • ID.3
    • 奥迪
    • 长城WEY,哈弗
  • 汽车是怎么开发出来的浅谈汽车开发流程
  • 在智能化赛道上,如何看待新造车势力与传统造车势力间的博弈局如何/li>
  • 未来汽车如何发展着电动化、智能化加快,哪些跨界技术会应用到汽车这一最有集成效果的载体上/li>
    • 变色玻璃VS车窗
    • 投影仪VS激光LED车灯
    • 手机电池VS纯电汽车续航
    • 座椅VS汽车座椅的外延
    • 耳机VS立体声与整车隔音
    • OLED曲面屏VS整车屏幕的布置
    • 家庭智能音箱VS车辆小助手
    • 手机传感器VS整车传感器
    • 手机变成了电脑VS汽车变成了家
    • 总结
  • 传感器攻防战-一文汇总自动驾驶的那些传感器
  • 汽车行业软件工程师发展前景如何IT 行业或互联网行业的软件工程师相比如何/li>
  • 华为能否成为下个博世/li>
    • 本文首发于汽车之家,本人原创,转载请联系本人。

浅谈汽车软件行业

前几天回答一个问题,讲述汽车行业的写代码的一些习惯,引来了不少争议,因此今天在这儿谈谈软件在汽车行业的现状。

之前有人问我,汽车行业也有码农吗/p>

确实,以前机械控制的时代,汽车行业确实没有码农一说,不过电控时代好多年了,而且随着电气化,智能化的深入发展,汽车行业对软件工程师的需求也越来越大。

汽车软件属于嵌入式软件开发,跟互联网行业软件开发差别很大。

汽车软件开发特点

一:基于模型的开发MBD

MBD的全称是Model Based Design,基于模型设计能够节省开发时间和成本。MBD 的主要优势在于:

1, 图形化设计

汽车软件大部分是基于模型的软件开发。这一点在大公司尤为明显,我们用Simulink将要实现的逻辑用图像的形式表现出来。图形化的设计逻辑明确,清晰,便于交流和维护。对于代码的第一任作者以及以后可能的作者,他们只需要看懂图形,就能知道代码实现了什么功能。而如果不看图,要去重新翻阅成千上百行代码,非常耗时。

img

这个标准包括了大概100多条C语言编码标准,目的是为了帮助汽车厂商开发出安全,高可靠性的嵌入式软件。有些编码标准让其他行业码农看上去都觉得可笑,比如下面这几条:

Rule 1: 不得使用三元操作符;

Rule2: 所有标识符不得超过31字符;

Rule3:不得残留被注释掉的代码;

Rule4:不得使用goto以及continue;

如果完全按照这个标准来书写代码,则你的代码是可读性强,可靠,可移植性强和易于维护的。遵循这个标准对于代码的质量也能起到很好的管理作用,不过Misra标准过于严苛,一般企业都会根据实际情况执行。

三:软件架构的统一

代码编写由规范,软件架构就更有统一规范了。

这就是AUTOSAR(AUTOmotive Open System Architecture 汽车开放系统架构)。

imgAUTOSAR三层架构

AUTOSAR的优点在于可以模块化设计,并将“配置”的理念深入到软件开发中,真正让软件变成可设计的,能即插即用的软件结构。

汽车行业与互联网行业软件开发区别

经常看到一些观点说汽车行业是传统行业,保守;互联网行业是新兴行业,创新有活力。

就连同为造车的新公司都忙着和传统汽车企业撇清关系,说我们是造车新势力,互联网公司。。

相比互联网行业软件能够快速迭代开发,远程升级;汽车行业只能按部就班走流程来设计软件,因此汽车嵌入式软件是为互联网的码农所不齿的,因为我们开发速度跟不上互联网速度。

想来想去,两个行业的软件最大的区别是什么代码数量还是架构不一样吗些只是技术层面的东西,我觉的是汽车软件更侧重安全和可靠性。

互联网的软件,如果有bug,只需要后台进行推送更新升级就行,顶多造成使用不方便,一般不会有人生事故和财产损失。而汽车软件是容不下一个Bug,以及任何有歧义的代码。软件有问题轻会影响汽车正常使用,重则会造成生命财产安全。

而且,软件造成的问题后期保养维护很麻烦,需要安排大量人力物力进行售后,这对于汽车公司都是巨大的财产损失。

所以汽车软件必须小心翼翼,按照以下方法来干活:

使用自动代码,因为机器往往比人靠谱,不太会犯错;

即使手工代码,也严格按照汽车行业标准来书写,保证没有歧义,没有意外的情况发生;

在开发过程中,我们也按照ASPICE流程来指导我们的开发和测试,保证软件符合需求,并且质量过关;

同时,汽车软件还有功能安全来进行冗余设计,防止软件可能的故障造成无可挽回的后果。

也就是因为汽车软件开发有这么多条条框框需要遵守,每一个软件使用前都有这么多流程需要走完,因此,汽车软件基本就跟“快速响应”,“迭代开发”这些名词无缘了。

所以我们一直被造车新势力称为“传统造车企业”。

汽车行业软件工程师都是些什么人

目前汽车行业无论是传统ECU开发,混动/电动控制器/自动驾驶都离不开软件工程师。不过汽车行业的码农不同于其他行业,这个行业要求码农们不仅仅要精通代码,还要有以下技能树:

1, 对汽车/受控系统要十分了解。无论是传统车还是自动驾驶系统,都需要对汽车有一定的了解,不然无法开发控制算法。而汽车又是个十分复杂的机械系统,不是临时看看资料就能了解的,因此汽车行业的码农都需要有一定的机械学科背景。

2, 电学知识。汽车软件要接收来自传感器的大量的外部信号输入,包括各种数字信号(开关信号),模拟信号(传感器值),软件工程师有时候需要对这些值进行滤波,计算,转换为自己有意义的输入。因此对于想加入汽车软件行业的初学者也需要一定的电学基础。

3, 需要标定能力。汽车软件很多算法是无法在开发软件的时候得到,需要后期在实车/Labcar上实验得到。所以汽车软件的标定功能是强于其他行业的,汽车软件工程师也需要一定的标定能力来测试和开发软件。

汽车软件行业趋势

1, ECU整合度将提升

早在去年,大众就宣布力争让汽车上只有一个ECU。在一些供应商巨头内部,确实也在这么做。特别是在ADAS和自动驾驶下,整合的ECU架构尤为重要。

2, ECU将承载更多的传感器

未来汽车将需要更多的传感器来感知环境,以及保证依靠传感器来保证冗余设计。这对ECU的能力来说也是考验。不过高级算法与机器学习的发展,有望取代一部分传感器,减少传感器数量。

3, 汽车以太网发展

长期以来,汽车ECU都是在一个封闭的网络环境下。不过随着智能汽车技术,物联网的发展,很有可能会催生汽车以太网,实现跨域通信。不过如何保证功能安全,这将又是对汽车软件的一大考验。

汽车软件的现状和发展方向

本文首发于EE汽车荟,在微信公众号搜索“EE汽车荟”可以查看。

如需转载,请联系本作者:汽车搬运工王先生。

简介:本文就目前比较热的“汽车软件”话题,做一些讨论。也试图回答大家比较关心的三个问题。内容主要有三方面:1)传统汽车是否有软件,为什么传统汽车业看起来像是被动地发展汽车软件)现在新能源车普遍拥有的语音控制系统,自动泊车,拥堵跟随系统,是否可以认为是革命性的汽车软件)汽车软件的前景如何哪些瓶颈技术以及创新/h2>

一.传统汽车的软件现状如何/strong>

互联网人看传统汽车的软件,就像普通观众去博物馆看看考古发掘。这么又老又笨的系统怎么还在世,还没被革命呢!在新四化的趋势下,传统汽车的软件发展仿佛是口诛笔伐的旧社会代表,被无数进步势力不断diss。然而,拥有这些老掉牙软件的传统汽车却像野草一样,不但没有没落,而且还在扩张领地。对于比较新潮的互联网软件,传统汽车似乎完全不搭界。

那么传统汽车真的有软件吗果有,这样的软件还有生命力吗统汽车的软件发展,怎么这么慢/p>

拿比较简单的空调系统来举例说一下。当天气比较热时候,这时候需要把空调的温度调低,比方说,从26度调到22度。我们看下汽车内部是怎么运作的:Step1: 驾驶员手动给空调旋钮一个信号,将温度调整到22度。Step2: 空调控制单元接收到信号后,从车外,出风口等地方收集信息,以决定下一步送风量。Step3: 空调控制单元给予风门控制器一个信号,把风门的角度变大。Step4: 空调控制单元给压缩机一个信号,让压缩机运转,保证后续冷风的供给。完成这个循环后,空调控制单元会重复Step2以决定后续的送风量,风门开启角度。

说明:1)其实Step3和Step4一般是同时进行的,为了简便将其分为两步。2)一般会在空调控制单元本身会附有室内温度传感器,以判定室内温度。这个信号也要传递给空调控制单元。3)手动空调没这么多传感器,主要靠人来感觉温度是否合适,不过其内部有一些经验值参数以及逻辑设定。

img

从简图中可以看到在语音转化为命令过程中,产生了一个所谓的输入,输出,反馈系统,这就再次形成了一个汽车内部系统。因此在车机里面,集成了语音识别软件,当然也有所谓的内存,缓存,处理器等。只是车机的处理任务,相比我们传统汽车的空调控制器来说,要复杂很多,语音除了可以控制空调,也能控制整车的娱乐系统,天窗和车门玻璃的开合。

目前应用比较广泛的智能系统,我们会发现这些都是偏信息娱乐类的,也叫汽车舒适域。一旦涉及到整车的动力/驾驶,就只有很少的车企涉猎,并建立控制系统。现在所说的智能系统,很多都是从传统车本身就有的自适应巡航,自动泊车改造而来。所以,可以这么理解,现阶段大部分所谓的智能汽车,实现比较多的是把手机搬到了车机的显示屏上,这样整车可以显示更多的信息,实现车主的娱乐需求,完成一些简单的车辆控制。而汽车的核心–驾驶系统,目前还独立在智能之外。只有自适应巡航,自动泊车这些所谓的智能软件的发展,才算触及到了汽车功能的底层,而真正的自动驾驶,才可以称作用软件重新定义了汽车。

在传统车的网络架构里面,舒适域和行驶域是通过网关隔开的,也就是说舒适域无法去指挥行驶系统,只能通过我们的肢体动作来影响车辆行驶。也就说,一个车怎么“娱乐”都不会影响到整车的驾驶。为了方便理解整车娱乐和整车行驶系统的区别,我们举例说明下自适应巡航系统的过程:Step1:汽车得到自适应巡航的指令;Step2:采集雷达信号;Step3:采集ESP和转速信号;Step4:根据采集到的参数计算,调节喷油量;Step5: 调节变速箱档位;Step6: 调节制动压力。这里面Step2/3基本是同步完成的,Step4/5/6也是基本同步完成。从这个系统中,我们看到软件系统,开始介入到整车最核心的底层,也就是发动机/制动机构的操作。我们可以说,这才是真正的汽车软件。这个系统的计算量,对安全性的要求,和娱乐系统相比,都要高出一大截。而且这个系统的“大脑”是整车最重要的ECU,它亲自指挥了这个系统,在重要性上,传统车的ECU高于一切,这就是整车运作的基础骨架。

img

相比于现在传统汽车分散的控制器以及软件,Tesla有三个核心的“处理单元”:自动驾驶和娱乐模块,左侧车身控制器,右侧车身控制器。第一个模块负责驾驶辅助/娱乐系统,也可以说这个系统可以深入到汽车控制的底层。后两个分管了汽车的车门,灯光,底盘系统。其实这个架构非常像电脑的架构,电脑有所谓的南桥北桥,也有CPU,在电脑上各个硬件的交互非常成熟,也非常流畅,有业内人士指出Tesla车身电器架构的设计之初就是借鉴了电脑的架构,所以从这个角度来说,Tesla的整车,更像行走的电脑。相比于现在其他主机厂的汽车,还是在汽车上增加电器的模式,如果Tesla的道路证明是成功的,那么现在来看,Tesla对于目前市面上的车来说,是一个革命性的存在。

除此之外,Tesla还有自己的电池管理系统,热管理系统,能源分配系统等,这里不是我们讨论的重点,就不再累述。除了以上架构的不同,Tesla在内部也启用了车内网。从实际的使用体验来看,Tesla有更多的人车交互,这带来的更多的乐趣。所以很多人评论说,Tesla更像一个Computer,而其他的汽车更像Machine。

从上面Tesla的例子来说,它至少实现了我们所说的几个未来趋势:软件整合,车内网以及更多的传感器的接管(在某些功能上Tesla其实不算传感器最多的,其他新能源车如小鹏有更多的传感器)。在可见的商业领域,Tesla可能代表了未来的趋势。从瓶颈上来说,还有三个技术难点:1)传感器,特别是激光雷达的技术革新和价格降低2)各种软件的进一步道路试验,已进行安全性的改进,如自动驾驶还需要更长里程的实验,以及各种场景的实验。3)如何用用更稳定的车内网来替代现有的信号线,以带来更大的硬件和软件空间。

从可见的将来来看,整车的智能化,会更快的上来,只是没有互联网所说的那些“迭代”那么快而已。第1点和3点,对业界来说都一样,大家的起点一致,也受限于几家硬件供应商。第2点,各个主机厂的准备情况和道路也都不一样,有Tesla的自己设计验证,也有大众投入巨大的MEB+VW.OS,通用的Cruise,谷歌的Waymo。有长于创新,制造出颠覆性产品的参与者;也有长于安全,制造出可靠产品的参与者;还有完全的非汽车行业的跨界者。最终的胜出,我想不是一个选择题,而是一个整合题。


泻药,回答这个问题我们首先要理解什么是“软件定义汽车”,为什么这个事有必要,并深入了解什么最终决定了”软定车”的成败。文章略长,由浅入深,可放心食用。

如何理解「软件定义汽车」/h1>

只要你知道什么是手机就知道什么是“软件定义汽车”,以及为什么这个事有必要,却又为什么很难,必须上升到战略层面来看这个问题。

传统汽车到底出现了什么问题/h2>

假设你有一手机,可以刷个弹幕,拍个照,吃个鸡。实现了多样化的功能,而这些功能的切换,更新往往在几分钟里面就完成了。
假设你有一汽车,可以听广播,你说那能不能,让这个车跳个舞吧,假设车厂认可你的需求,保守估计你得等个2年

客户爸爸已经越来越不能满足车辆功能的开发周期,期待更快的功能迭代,而车不能满足这个需求。当有一个车厂开始干了这个事情。其他车企就是隔代的竞争,这就是为什么会有“软件定义汽车”,核心是应对客户日益增加的迭代需求。

软件定义汽车,说直白点,就是把车做成手机

img

然而客户说明天我就要一个新功能,噩梦就开始了。

img

传统车辆电气结构就是以CAN网关为中心的多个独立小控制器,车厂的工作简单来说就是定义好要什么功能,供应商给个小控制器(VCU)实现,然后供应商告诉车厂,我的控制器要正常工作,需要什么信号进,要什么信号出,车厂把他设计到整车DBC中,形成一种CAN上大家互传信息的公共协议。所有功能基本就可以RUN起来。

然而当客户的更新需求越来越快的时候这个方法就不靠谱了。

如果客户要增加一个功能。控制器A要变化->CAN协议和链路要发生变化->用到这个协议的其他控制器也要变化->如果这个功能要增加一个新的控制器,则整个线束连接都要发生变化。然后供应商A,供应商B,供应商C排着队问车企要变更费用,要开发周期(半年-1年)更遭罪的,这种变更哪怕要更新软件,也要去4S店,或者压根不可能,下一次变更需要再等1年。这些零零散散的控制器相互耦合,导致了车辆无法快速的进行功能迭代。

而反观手机就没有这种问题,原因就是整个手机只拥有一套芯片,一套控制器,一套操作系统,软件在这个基础上的任意更改变得容易很多,并且不需要对硬件作出什么变更。再次说明了,软件定义汽车就是要让汽车变成手机,变成计算机,可以安装自己喜欢的软件,可以随时更新软件版本,便捷快速,即安即用。就如同题主说的,未来的智能汽车如果给你的感觉,是在一台“超级计算机”上安了四个轮子,那他就成功了。因为一个计算机就可以很好的更新功能。

总结下,**为什么会要做软件定义汽车*因为需要解决客户爸爸日益增加的功能需求和缓慢的整车开发流程之间的矛盾。**软件定义汽车做了什么**让整个系统在硬件上拥有更高的集中度,在软件上拥有更广泛的灵活性。技术细节我写了四篇文章,需要专业分析的可以看下



1、为什么软件定义汽车/strong>

  • 整车代码量和复杂度增加

对比于传统汽车的 “三大件”定义汽车,消费者关注于发动机、变速器和底盘。随着汽车不断走向智能化和网联化,消费者将开始关注差异化和科技感的配置,功能的实现严重依附于软件,因而汽车代码数量和复杂度也日益增加,软件在整车的研发成本也越来越高。

  • OEM研发模式的优化

站在OEM角度,需要OTA来实现功能的完善、算法的更新、BUG的修复和成本的优化等。另外在激烈的竞争下,硬件利润空间在不断压缩,OEM参考消费级产品靠售后的软件及服务收费分摊一次性硬件成本的模式,开始在售后软件生态、技术付费上进行探索,需要消费者来为自动驾驶等功能高额的软件开发成本买单。

  • 消费者需求的改变

站在消费者角度,靠传统硬件差异化配置有无,不足以满足差异化需求,需要更多的软件配置来提升使用体验生活,如:个性化界面显示、自动驾驶、智能音视频交互等,普通消费者需要花钱来感受更多的科技体验,等同于现在互联网付费服务。

2、软件如何定义汽车/h2>
  • 软件定义汽车的功能和性能

智能驾驶、车联网、智能座舱等功能的实现,都主要由于软件来定义,如底层软件Autosar,操作系统QNX、Andriod等,安全软件OTA,还有娱乐化、智能化应用等。

软件决定产品的性能,类似于手机的操作系统,软件的可靠度将直接影响产品的性能。而且汽车还涉及到一些安全层面的功能,黑科技功能不断增加的同时,软件显得更加至关重要。

  • 软件缩短功能的迭代周期

传统汽车厂商的销售方式是以销售的实现为终点,“只管生不管养”的模式,依托车型的年改、中改、大改、换代来实现机械硬件更新,迭代周期和成本也很高。消费者对新技术的尝试只能换车,成本相对较高,传统汽车的软件更新几乎与汽车生命周期同步,极大地影响了用户体验。

特斯拉能够通过硬件升级+软件OTA做到常用常新,软件OTA降成本的同时,大大缩短功能的迭代周期,给消费者带来用户体验的极大提升,其功能付费升级模式也逐渐被传统OEM效仿,国产供应商的产品开发流程和售后维护提供新的思路。目前的传统OEM与特斯拉,有点像诺基亚与苹果的关系,但特斯拉是不是颠覆者还有待时间验证。

img
  • 半导体算力的提升

整车电子电气架构的集中化,需要半导体算力的满足,如自动驾驶的落地需要一颗小型化、算力强大的计算平台,而不是整个后背箱工控机,如Mobileye的Eye Q4/Q5、英伟达Drive系列、华为的MDC600、特斯拉的FSD,还需要与之配套的运存LPDDR4/5及大容量存储eMMC/UFS/SSD等用于数据的处理和保存。国产OEM厂商可能没有芯片自研能力,可以与供应商合作来满足自身域控制器的研发需求。

img

img博世电子电器架构研究研究

这里还是要再专业点描述这个问题,在软件定义汽车思维下有三个重要的关注点

**硬件成本进一步降低:**相同功能需求下,减少 ECU(电子控制单元)数量,可以降低 ECU 物料成本,另一方面也进一步减少了整车线束使用量。Model S 线束约 3 公里长,而 Model 3 缩短了近 1 倍。

**硬件抽象:**此前的供应体系是供应商将「软件+零部件」打包卖给主机厂,软硬件的耦合很深,议价能力差,测试调试苦难。特斯拉的牛叉在于软件基本自己写,即便更换硬件供应商,也不会显著影响软件功能的部署。

**OTA升级:**在硬件抽象的基础上,特斯拉可以通过 OTA 的方式进行新功能的更新下放,以及对车辆状况进行良好监控,降低维修成本。整车软件开发变得更多样化,更简单。

一个最经典例子:特斯拉通过 OTA 解决制动距离过长的问题。彼时 Consumer Reports(消费者报告)发布的特斯拉 Model 3 测评中指出,这台车的 60mph-0 刹停距离并不理想,达到了 46.33 米,但是经过 OTA,Model 3 的刹车距离得到了显著提升。

img

没有OTA或者域控制器之前,智能驾驶功能必须要等到底盘性能完全冻结才能开始进行标定、调教和测试,虽然多数时候会分多个迭代过程,进行多个周期的调试,但不管哪个周期,智能驾驶功能永远是拍在最后的。一旦前面的某些开发出现了延期,在量产前最着急最痛苦的就是智能驾驶工程师,因为压缩的基本都是他们性能提升和测试的时间。

自动驾驶的研发周期理论上就不可能和整车研发周期契合!

无论生物成长还是汽车制造基本都一个道理:简单构件往往会优先产生并投入工作,以支持复杂构建的产生,骨架,心肺,往往都会优先形成机能并支持大脑器官的发育,后者的成熟周期往往是最长的。不同器官需要处理的任务维度不同,因此复杂度也不同

就像小宝宝,如果它脑袋在出了娘胎后就不成长(传统电气架构),那牛津大学也要在娘胎里读了。虽然骨架,肌肉,心肺都可以在出生前健全,但10个月时间脑子的核心功能是好不了的,他需要对接外部环境。但如果可以后天学习,那ok了,差不多时候我就可以从娘胎里出来了。

OTA或者域控制器的产生,为自动驾驶等功能释放了更多空间和时间,让其开发周期和测试周期得到必要的保障。

你以为结束了件定义汽车的工程师刚刚完成了第一步!

把硬件折腾清楚了,充其量就是车的硬件基本可以和一台电脑或者一部手机相比较了,可这些东西可以真正工作起来还缺个操作系统哈(什么android,Windows,Linux),那汽车的操作系统是什么/p>

请看第二篇

殷玮:软件定义汽车(2)-软件中间件

软件定义汽车(2)-软件中间件(Autosar为例)

工程师们把硬件折腾的差不多了,嗯,是不是可以开始应用软件快乐的开发了,还不是哈,我们都知道手机,电脑啥的在应用之下,硬件之上,还有一个东西叫操作系统,车辆里也有类似的东西。

操作系统,中间件,

来源:小熊coder

声明:本站部分文章及图片转载于互联网,内容版权归原作者所有,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2022年6月12日
下一篇 2022年6月12日

相关推荐