由爱因斯坦汽车、奥托组织、上海车展共同主办的2021第二届软件定义汽车峰会论坛暨奥托中国成功举办,本届论坛也是第十九届上海国际汽车工业展览会的同期活动。 此次会议邀请北汽研究院智能网联中心专业总师褐景尧先生在本次论坛上发表了题为“车载软件的开发与挑战”的主题演讲,以下为

“北汽车联网专业总师褚景尧:整车智能化下车载软件的开发和挑战”

大家早上好。 各位嘉宾和车同事,大家好。 我是北汽研究院的褚景尧。 我想通过盖乌斯的再次邀请和大家分享车载软件的开发,和大家一起讨论这个大话题。

我演讲的主题是整车智能化下的车载软件开发和挑战。 说实话,接到邀请的时候,我还是心怦怦跳。 首先,这个话题非常大,非常难。 与以前流传的汽车人相比,讲软件更容易掉进技术的坑里,与软件开发者相比,讲汽车的多与杂,就觉得不容易跳上汽车的长远规划,将两者融合在一起。 其次,我两年前和大家分享过一次。 作为汽车工程师,我还在乐队门上摆弄过斧头。 思考了一会儿之后,我决定换行头,作为程序员和大家分享一次。 我也做过10多年的软件开发,所以软件领域日新月异,我肯定说错话了,请批评和指正。 有了tesla,造车新势力是三驾马车的明珠,但最大的软件企业中的苹果、谷歌造车计划还停留在纸面上,之前有消息称主机厂的大众、丰田、bba等软件实施计划不顺利, 因此,此次共享的重点是如何构建两者之间的桥梁和纽带,促进两个领域的迅速融合,提供自己的建议和意见。 关于软件如何定义汽车,什么时候定义,话题太大了,这次只做浅学,不细说。

“北汽车联网专业总师褚景尧:整车智能化下车载软件的开发和挑战”

其实,请想想ict技术是否如此成熟,软件定义手机,软件定义家电是否成为了众所周知的互联网术语。 没有。 软件定义的核心思想是把软件的地位和硬件放在同等重要的位置上 正如小平先生所说,认为“无论是用双手抓住还是用双手抓住都要牢牢抓住”,将硬件和软件解除结合,实现api的标准化,使所有东西都可以编程,开发丰富的场景、APP、服务 汽车是一个非常复杂的硬件和软件系统,其前提是定义“充分、必要、保证系统可靠升级”的硬件平台,基于稳定的硬件平台 不要无限夸大软件的能力。 这才符合软件,乃至汽车软件的准确快速的发展规律。

“北汽车联网专业总师褚景尧:整车智能化下车载软件的开发和挑战”

两年前出现了软件开发、软件功能赋予、软件驱动三个阶段。 经过两年的高速增长,个体需要调整以下顺序,同时增加“软件定义汽车”的阶段。 第一阶段是软件可以工作。 毫无疑问,大力推广智能车提高了自主企业品牌的曝光量,也促进了汽车的销量。 此外,一些软件功能和客户采用流量将创造不同于整车销售的新的盈利价值。 在此也要报告一下,北汽车网络平台的数据显示,客户无限流量免费两年后约5%~10%的流量持续率,虽然数量不多,但迈出了可喜的一步,远远超出了我们的期待。 当然收益价值不仅包括直接的金钱回报,还包括提高顾客体验、提高舒适性、提高安全性、提高行驶便利性,无论是自动驾驶还是智能客舱都或多或少提供了这些技术支持,为产品力和企业品牌力做出了一定的贡献。 当然得到的肯定会失去,智能化的背后是零部件价格的上涨和高昂的开发费,权衡利弊后,主机厂意识到了战场的转移。 于是迅速进入了第二阶段。 是自主软件开发。 随着造车新势力的自主软件开发,以前流传的车企将带动铺天盖地的软件人员招聘和合资企业成立的新闻。 基本上,可以理解为自主企业品牌正在攀登软件开发这座大山。 目前,汽车领域在智能网的大趋势下,所有主机厂都在增加投资,招聘软件开发者,搭建开发平台,搭建开发工具,开发软件测试工具和验证平台,为未来出力 一旦软件能够自主开发,软件驱动就变成了水到渠成的事件。 当然这是一个非常困难的事件,需要识别现有技术的科技载体、巨大的商业价值、填补市场的空怀特、或巨大的受众群体等巨大的商机。 领先的技术生涯一定会最先登场。 如果说汽车是当今机械和电子电气的最高结合载体,那么实现自动驾驶是最重要的目标,也是全体汽车人的梦想。 自动驾驶一旦实现,就会产生巨大的商业价值,可以填补市场空的空白。 虽然受众群体没有手机那么庞大,但一旦实现了软件平台化,就会产生专属行业内的专属价值,就像Wechat、qq音乐、百度地图、嘀嗒不依赖手机企业品牌一样。 自动驾驶已经成熟,个人觉得用软件定义汽车的时代已经到来。 首先,汽车的属性发生了根本性的变化。 虽然移动是必要的,但不是首要问题。 旅行中能做的事是核心。 根据时间段,呼叫什么性质的车(可以说这个时候开车是错的。 因为人可以在车里做自己喜欢的事……)。 而且,如果车辆实现了自动驾驶,车的形状可能就无关了。 平台化的底盘、模块化的配置、商业化的诉求、个性化的外形,才能真正打造出属于自己的车。 如所示,( Richards Carry ( ScarsandTruckSandthingsthatgo ) )车辆形状不同,用途不同,依然在道路上顺利行驶。 如果童话切合现实,汽车领域会更丰富,软件的价值会更大,发挥更核心的价值。 最后是轿车和商务车是否还有区别,但需要在整个领域仔细考虑。 如果自动驾驶车呼叫后马上到达,可以根据移动中的用途选择不同属性的车辆,有必要购买私家车吗? 这个话题很有趣,希望有机会和大家一起重新构想未来。

“北汽车联网专业总师褚景尧:整车智能化下车载软件的开发和挑战”

所以汽车智能化、软件化还是需要不断探索、不断前进。 我们仍然想通过手机智能化的开发之路来支撑我们。 手机和汽车的大屏幕显示、主控制器、传感器、电源管理、大数据、导航等应用非常相似,所以手机的快速发展无疑能够有力地支撑智能车的快速发展。

“北汽车联网专业总师褚景尧:整车智能化下车载软件的开发和挑战”

首先介绍手机从功能机进化为智能手机的几个重要因素。 第一、包括高性能硬件、高性能芯片和高性能传感器。 这不是正文的要点,不细说。 第二,高速通信互联网是智能手机快速发展的基础。 如果每个人都经历过2g/3g网速非常慢的时代,你就会明白那个时代其实并不是对智能手机有诉求。 网页需要刷半天,qq聊天比邮件好。 在线视频、游戏总卡片机、那个时代的智能手机都不是智能手机。 第三,强大的开源操作系统(开源对中国、对美国不太实用)。 操作系统是软件开发集大成的产物,在概念上与汽车不是很相似吗? 如果没有谷歌的开源操作系统,就没有高端智能手机时代。 准确地说,没有现在的华为、小米、ov、三星、sony等百花盛开。 第四,开放的开发者平台。 无论是谷歌的安卓还是苹果的IOsOS,都精心设计了易于获取、易于开发的开放开发者平台。 这吸引了大部分国家和个人忘记了操作系统的重要性,转向开发入门简单、开发容易、效果更好的应用商店和应用市场。 五、丰富多彩的APP研发。 这是一款满足众多顾客所高兴的各种各样欲望的APP。 可以说,通过人口红利和高体验服务,实现软件快速获取优势价值,APP应用促进手机转换的力度非常大。

“北汽车联网专业总师褚景尧:整车智能化下车载软件的开发和挑战”

由上可知,汽车智能化所需的转换条件基本一致。 以高性能硬件、高速通信互联网(车内和车外)等硬件为基础,强大的操作系统)、开源和开源)、开放的开发者平台、丰富多彩的APP开发

简单来说,有手机软件的两种开发逻辑。 一个在国外,另一个在国内。 国外的开发流程是什么? 无论是功能机的symbian,还是智能时代的安卓和ios,首先都会看到操作系统,然后是开发者平台,然后是APP,但这些背后都是编程语言。 现在中国的状态是,APP排在第一位,其次是基于特定技术APP的开发者平台,其次是操作系统( os )。 无论如何,中国的商用操作系统已经启动,无论是alios,还是harmonyos,都会鼓舞我们的士气。 说到os,我按捺不住好奇心去了国产os。 虽然都是linux版,但我希望能尽快增加能普及到国产预装pc/laptop/phone的商业化版操作系统。 关于编程语言,至少普遍使用的编程语言在我国至今仍为零。 c、c+、objective-c语言之父是美国人,这些编程语言对汽车软件开发很重要。 稍后我会讲几句,希望你记住。 连日本都发明了编程语言,而且通过东方的理念“重视人的作用,人会成为计算机的主人”来开发编程语言,所以我们还有很长的路要走。

“北汽车联网专业总师褚景尧:整车智能化下车载软件的开发和挑战”

关于OSOS的开源还是不开源,将在这里进一步详细叙述。 我们知道手机有两大操作系统。 (目前鸿蒙操作系统尚未统计。 一个是谷歌的安卓操作系统,另一个是苹果的ios操作系统。 由于目前操作系统的能力还很弱,许多主机厂都在使用autosar软件架构开发新的架构和智能运行。 让我们先来看看tesla。 这个诱惑整车智能化的主机厂用的是什么操作系统? 所以我登录了tesla的github。 URL是千兆以太网/特斯拉汽车。 我发现了非常有效的信息。 让我们先来看看linuxsources。 这也与我们希望在信息中采用linux操作系统一致。 然后,我看到了reactnative。 react是facebook开发的javascript库,采用这个库可以很好地制作漂亮的网页ui,简化前端程序员的很多操作。 react native是以react为基础迅速发展起来的,其目的是让程序员实际上可以使用javascript开发手机端的app。 就像浏览webapp一样,有本机app的流程和操作体验。 还有小的rocksolidproductions。 产品为creationanddesignofmotiongraphicprojects。 该语言为objective-c,证明是tesla开发的IOs应用程序。 此前谷歌和tesla就激光雷达和高精度地图进行了多年的讨论,这是否意识到这个tesla发生了变化? 最右边的top language中no.1居然是ruby。 看来脚本语言在世界范围内也很流行。 幸好还有c +。 c支撑着场面。 否则我不知道tesla在做什么。 如果今天有tesla的朋友的话,我想在线交流。 那么,问题来了。 tesla没有autosar体系结构,而是像苹果的ios系统一样自己开发,使用自己定义的东西。 这值得深思。

“北汽车联网专业总师褚景尧:整车智能化下车载软件的开发和挑战”

接下来谈谈autosar,推测一下为什么tesla在使用linux吧。 明天是燕麦中国日,而且这里燕麦专家太多了,所以我拿不到斧头。 从利益上讲,autosa的终极奥秘在于它可以解除软件与硬件的连接、实现软件的标准化、硬件的更换。 这让我想起了中关村海龙大厦的电脑城,也就是以前流传下来的电脑。 但是,储存电脑时会选择cpu、主板、内存、显卡等,而汽车则是adas模块、apa模块、车身控制模块、电源和底盘控制模块、bms控制模块等 对于主机制造商来说,如果第1层的部件开发使用autosar软件体系结构,主机制造商也使用相同的autosar管理互联网体系结构,那么主机制造商会在意哪个第1层提供部件,哪个第1层提供部件。 直接找性价比最高的第1层,绕道超越,自己搭建场景,开发上层功能就ok了。 所以,据说autosar的出现极大地处理了主机厂和供应商之间最大的烦恼。 那为什么tesla不用autosar呢? 1 .雄厚的软件开发力。 硅谷三强+亚马逊,其中苹果和谷歌还在造车的漩涡中。 2. allin的控制能力。 tesla希望控制ecu各阶段的开发,其电池和bms的开发充分证明了这些。 但是基于autosar开发的控制器基础软件业务由供应商完成,供应商占绝对主导权,主机制造商想要整车ota需要通过供应商完成。 3 .强大的扩展性。 智力代表什么,代表ai,灵活多样,常用总是新的吗? 将来承担自动驾驶的是强大的计算平台和系统架构,从tesla的角度来看,如果没有与之完全匹配的操作系统,应该是无法控制的。 我想这就是为什么tesla开发了自己的操作系统的原因。 回过头来看,这和我刚才说的国内外软件开发模式有点像吗? 作为新一代的汽车制造商,有必要深入思考中国应该怎么做,应该是什么样的开发模式。 现在受条件限制,即使不能从编程语言、操作系统开始,也应该意识到问题的根本原因。 “师夷制夷”,明确了adaptive autosar可以承载到那个时刻,其水平、进入那里是基本的。

“北汽车联网专业总师褚景尧:整车智能化下车载软件的开发和挑战”

说到autosar,还必须提到另一个组织。 misra全称是“The MOTORIND UST RySOF Wareliability Association汽车工业可靠性联合协会”,成员包括大部分欧美汽车制造商。 在座的很多人可能没听说过这个组织。 但是,他们和燕麦的关系越来越近了。 最新消息显示,misra c++和autosar c++未来的合并,两个主要安全至关重要的c+编码标准的合并,对使用autosar的主机制造商和供应商都是巨大的利益,至少是未来的软件编码。 misra目前有四种指南:自动编码、安全分析、c和c +。 其中,c、c +是严格的语言编码规范。 以misra c编码标准为例。 该标准包括约100多种c语言代码标准以帮助汽车制造商开发安全可靠的嵌入式软件。 有些编码标准让其他领域的开发者感到奇怪。 例如,如下所示。 不能使用逗号运算符。 不得采用三元算子; 请勿使用goto和continue语句; 不能采用动态堆的内存分配。 为了避免采用函数alloc、malloc、realloc和free,必须小心地采用库string.h中的函数。 完全按照这个标准写代码,首先代码简单易懂,有吸引力,可靠,可移植性高,容易维护,其次可以轻松达到高功能安全水平。 但是,misra标准太严格了,主机厂必须根据现实情况执行。

“北汽车联网专业总师褚景尧:整车智能化下车载软件的开发和挑战”

和autsa谈完之后,我们来谈谈soa的事吧。 这个面向服务的分布式体系结构是不是很难理解? 但是,与之对应的体系结构——c/s和b/s体系结构,大家是不是都觉得恍如恍然大悟呢? 因此,soa是云服务开发法和部署中非常常用的架构。 c/s最好理解一个客户端( APP )对应一个服务器。 b/s是桌面即浏览器,浏览器可以进行任何事件。 服务器端分层、前端APP服务数据解析+ APP接口、后端存储和数据分解。 soa是b/s的再扩展,将不同的服务引入不同的服务是专门针对术业的,中间层通过http链路或套接字的rpc调用获取云服务。 生成xml或json的标准数据,嵌入不同终端的不同项目中,完成程序的开发。 (这张图是我从网上得到的。 如果有侵害行为,请马上联系。 利润是,服务功能的更新只需要更新引入到自己身上的服务,不需要更新其他服务的服务,也不需要根据终端的不同而有所更新。 我们回到车侧,基于autosar开发的整个中央智能安全网络基本上使用了这一架构,由之前流传的互联网信号构成了一个个的小服务,保证了基础传感器或控制器的独立性, 有了这个领域的专家,我们随时可以表达信息,不断修订和修正我们开发中的问题。 但是,我个人认为soa的用途在于将来的自动驾驶。 中国汽车学会对ICV技术路线图2.0的解读表明,自动驾驶对云和实时通信的要求,未来将部分计算力转移到云端也将是未来的方向。 那么实现云+1~2个计算平台、服务的2层或3层备份,使用soa架构也可以实现功能安全,是自动驾驶行业比较有效的处理方案。

“北汽车联网专业总师褚景尧:整车智能化下车载软件的开发和挑战”

如果有计算平台、autosar、soa体系结构,是否可以构建开发者平台? 我认为目前来说,定义并不简单。 开放平台有两种。 一个是系统级的开放平台。 基于操作系统,释放上层api,开发个性化的软件。 基于谷歌linux平台的开源手机操作系统被认为是最成功的开放平台,带来了中国手机领域的虚假繁荣。 目前,国内只有huawei的harmonyos和阿里的alios。 后者的开放平台已经发布了,你不知道这里有多少工程师在此基础上开发过APP吗? 如果有alios的工程师的话,我们也一起探讨一下吧。 另一个是应用层面的开放平台。 基于特定的技术,该技术将来将广泛应用,并倾向于被高数量级客户采用,开放相应的函数接口,开发易用的功能。 例如百度apollo、腾讯微信小程序、科大讯飞语音、小米iot等,都有助于迅速推进该技术的快速发展和应用,个人觉得目前还有很大的潜力。 那么,主机厂应该关闭还是开放? 开放是在系统级开发,还是以有自己核心的OS为前提,还是在APP级开放? 这些都是各主机厂内部不断探讨的话题,为什么? 因为难度很大。 一个是开发模式的冲突,另一个是系统层面多,复杂度高。

“北汽车联网专业总师褚景尧:整车智能化下车载软件的开发和挑战”

首先,对汽车的开发模式进行说明。 是a-spice 这一点在这里以前就被流传下来的汽车人熟知,现在各大主机厂的软件开发流程基本上都是按照a-spice制定的。 agile是互联网常用的开发模式。 如何将agile嵌入到a-spice开发中? 我认为有以下前提。 第一自主开发对智能化的诉求千变万化,如果没有自主开发,供应商的合同就无法签订。 要么增加天价开发费,要么造成sop delay,这个代价是主机厂无法承受的痛苦第二,项目、产品、开发、测试、质量、测试人员都很熟悉agile。 如果只有开发和测试,这里的测试意味着软件测试人员采用了敏捷开发模式,如果质量和测试人员没有意识到,软件开发和测试人员面临的将是灾难。 大家可以用大脑来弥补场景网络开发中产品经理和研发的爱互相残杀; 最后是ota,幸好有了ota,一切都有可能成为现实。 但是,要实现ota,整车开发过程的目标不是sop,而是汽车的整个生命周期,这就需要自主开发才能逆向推进软件。

“北汽车联网专业总师褚景尧:整车智能化下车载软件的开发和挑战”

接下来,就以下难点进行说明。 那是系统的多样性和复杂性。 面向计算平台的整个软件的体系结构基本上是这样的。 从底层来看,脱离硬件后首先是虚拟化平台,为什么不是直接操作系统? 既然是计算平台,就必须支持各种硬件,具备各种安全级别,所以解决这些问题的首要方法就是虚拟化。 虚拟化之后,是操作系统,除了多任务分时操作系统、posix系统之外,还要求实时操作系统有很高的要求,需要保证感知执行的实时性。 然后,用some/ip、doip、fota等通信协议,以及autosar和api构建标准的api和rte。 主机制造商有很多特点,保证之后的开发连续性。 你会问我为什么这么复杂,首先因为这是面向未来的自动驾驶。 未来的计算平台一定会更加复杂,但现在就必须考虑。 考虑座舱平台、驱动平台、云平台的协作能力。

“北汽车联网专业总师褚景尧:整车智能化下车载软件的开发和挑战”

不仅仅是系统的多样性和复杂性,还有技术的多样性和复杂性。 根据ICV2.0的技术路线图,我们发现软件非常多,涉及到方方面面。 我不一一叙述。 但在这些技术的背后,到底有什么? 编程语言和操作系统。 希望下次我参加盖世太保论坛的时候,这里会出现中国设计的编程语言和操作系统。

“北汽车联网专业总师褚景尧:整车智能化下车载软件的开发和挑战”

有困难,有多杂乱,道路都是曲折的,前途是光明的。 目前,多个领域的合作已经开始,下一步是完成自主研发和合作开发,搭建开发者平台,最后建立汽车自身的应用商店后,是我们汽车人的胜利。

标题:“北汽车联网专业总师褚景尧:整车智能化下车载软件的开发和挑战”

地址:http://www.0317jhgd.com//dfqcxw/15881.html