黄少堂:软件定义汽车,架构定义软件
8月26日,江铃汽车CTO兼总裁助理黄少堂受邀出席 “SAE 2020 汽车电子与软件技术论坛”,发表《软件定义汽车,架构定义软件》的主旨演讲。系统地阐述了软件定义汽车的背景、机会和挑战,并分析了顶层设计和实际执行中的痛点。
汽车圈内人士更习惯称他黄堂主,笔者听过很多CTO的演讲,很少有黄堂主这样,纯干货、零带货的。听众评价他的演讲,不仅有掌声,还有笑声,掌声代表礼貌和敬意,笑声才是内心的共鸣。
*本文是根据现场演讲整理而写,尚不能领悟黄堂主精髓是万一,仅供交流、参考。
今天所处的汽车时代,我们前人从来没有这么幸运过,也从来没有这么焦虑过,更没有体验过。 每一天都不一样,即使我这样有几十年汽车电子经验的老行家,面对今天这样从未经历过的世界,又能好到哪去了?
最近,我们一直在思考,为什么业内突然兴起软件定义汽车,而且如此红火。事实上,过去几年,如发动机的点火、喷油、排放,已经是软件控制了,底盘的AEB,还有自动刹车控制,包括自动转向。其实从底盘、传动、动力、车身,软件已经渗透到了几乎所有的汽车系统。但过去从没有像今天这样强调软件定义汽车。
另外,消费电子对汽车行业的冲击,人们的消费习惯和生活方式已经发生变化,促使人们的期望值不断的增加,人们不再忍受开一个豪华车,还用一个手机去导航。特别是90后、00后的消费者,他不再像我们这一代人买个宝马、奔驰,做点小生意,他们更强调个性化的展现。而当我们打开汽车行业的软件库时,发现我们的软件代码量已经超过了飞机,并不在其他行业之下。
02 特斯拉效应
特斯拉的设计语言和交互体验创新也是对传统汽车的一个全方位挑战。Model 3看起来简单的显示屏背后,大众做不到、通用也做不到。一个屏里面的几个模块,我们传统的整车厂有车身部、娱乐部、信息部,一个键,这么多部门谁去负责?软件内部又是如何集成?我们供应链里有一个企业能做这样的东西么?别看一个屏,其实用户并不关心多复杂的网络架构,也不关心ISO 26262,用户关注的是简单和极致的体验。而制造工艺、开发流程、工具链,还有供应链的整合,而复杂的逻辑只隐藏在背后。特斯拉还有强大的自身能力,现在绝大多数整车厂都受制于供应商。表面上看起来主机厂很强大,如果把汽车扒开,有多少是主机厂自己做的呢?特斯拉让整个行业进行了思考,重新定义汽车。
03 架构定义软件
首先要定义好架构,然后针对场景的设计,比如自动驾驶的场景、路面,娱乐系统,商用车、物流车的场景跟乘用车又不一样,场景定义就不一样。回顾汽车网络架构,以前只有电器架构,没有什么电子和软件。比如发动机点火就是用一个高压线圈,开关一弹,能量释放,产生火花,点火。油是共轨的,哪个阀门开了,就滴到哪个油缸里。后来才有了基于发动机的电子模块,也就有了电子电器架构。现在,随着智能网联汽车的发展,特别是自动驾驶以后,将演变成车、路、人协同电子架构。
在传统汽车人看来,Model 3 的架构简直是一个大杂烩,而传统的车企,如大众MEB的架构就比较规矩,很难说谁的更好。但用户其实并不关心你背后的设计,这就是我们需要思考的。
所以你说特斯拉完全不遵守26262和AUTOSAR,也有一定的道理。当他发现传统标准局限的时候,就需求创造出自己的路。
Model 3 的中央计算模块,采取区域控制,不是功能域控制,有人说是为了节省线束的成本。我的理解是,它把模块、智能配电、传统保险,都用电子保险控制了。而我们传统的网络架构,控制0和1,起步、唤醒、休眠。如果把电源都控制了,就不存在休眠、唤醒了,一通电都醒了,一断电都休了。既然把电分开了,就必须有前、左、右控制,如果把所有的保险都放一个盒子里,就变成烤箱了,所以有几级分电。这是基于功能的需要进行这样的定义。
- 传统软件应用开发,功能代码耦合,程序整体打包
- 修改部分逻辑,需整体重新编译
- 跨控制器功能分散,所有相关控制器都需要更新软件
新的软件架构下:
· 服务单独部署,代码解耦;
· 服务可编排和重组,形成新的功能应用。
今天,在域控制器的概念下,关键的模块都是自己开发的,你要改一个节点,或者要改不同的节点,可以通过功能定义,不再以模块去刷新一个,而是以服务包的形式进行更新。而且软件还可以进行整个生命周期的收费,改变车企的运行模式。原来汽车卖出去以后,跟车厂就没有多大关系了。
· 低成本软件故障解决和问题修复,
· 降低招回成本,
· 产品性能优化,
· 功能服务导入和迭代
· 提升人机交互和服务升级
· 用户体验持续提升
04 软件定义汽车
传统车企开发一个车往往需要三年,包括概念设计、定义方案,再冻结、下车体制做、样车制造、三高测试、标定等。如果软件定义汽车还在这样的流程下进行,三年前开发的软件,在三年后可能就已经被淘汰了。因此,软件定义汽车要颠覆整个汽车开发流程。这将是很多车企巨大的挑战,大公司制定流程往往是很大的梯队,而管理层中,基本都是做底盘、车身等传统部件的出身的,他们的软件的概念还比较缺乏。固化的流程让传统汽车人很安全、很可靠。这就制约了组织的更新和发展。
要实现软件定义汽车,要没有一个革命性的,从组织架构,CEO层面变革,只可能被淘汰。
我读MBA的时候,去过芬兰的诺基亚。当时,整个芬兰为诺基亚自豪,这么小的国家,诞生如此成功的企业,它的手机以质量著称,充电可以用一个星期。苹果出来的时候,我们都笑了,不小心掉地上,屏碎了,每天还要跟祈祷一样,把电源插上去充电。其实诺基亚并没有做错事,当初MBA的范例都是它的成功。如果我现在再去读MBA的话,范例会不会是它如何失败的。时代在变,即使你没有做错事,但别人做的比你更好。
很多机械类的东西,要改一个字,开一个模,到今天仍然需要上千万成本。而软件只需要一次开发费。并且可以个性化的定制,借用其他行业的生态。软件定义汽车的驱动因素具体表现在:
用户层面:
· 千人千面的用户使用需求
· 打造舒适的驾乘环境,改变未来出行方式
· 拥有丰富的自选应用
· OTA更新软件
· 无需硬件升级
OEM层面:
· 更短的开发周期
· 丰富的车辆变形管理
· SOP后快速的迭代更新
· 减少ECU软件升级周期和成本
· 标准I / O接口,软硬分离
· 开放的应用生态服务
· 丰富的产品研发和商业创新,即插即用的高效可扩展性
舒适的驾乘环境,改变未来出行方式
软件定义汽车赋能整个生命周期内,可以学习用户、车辆自身、周围环境并适时作出适应性调整。
05 软件定义汽车的要素
· OEM只是架构的定义者,只做系统集成工作,不做软件开发
· 各系统Tier1完成所有功能的软件开发
· 各系统较封闭从而形成信息孤岛,外部开发者无法对介入开发
· 代码无法复用,大量软件工作花费在不同软硬件的适配上
· 硬件产生价值
面向软件汽车的开发模型:
· OEM不仅仅只是架构的定义者以及系统集成者,还主导脱离底层操作系统以及硬件的基础软件平台和大部分策略层面软件的开发
· 各系统Tier1完成底层软件的开发
· 开放的应用服务生态,即插即用的高效可扩展性
· 软件产生价值,满足千人千面的用户需求
有人问,可不可以一步到位?虽然我们想这样,但一方面是自己没有这个能力,另一方面是供应商不是这么排的,而且这个过程是要跟供应商及整个供应链讨论的。你有多大的市场?怎么玩?谁有权力去定义这个规则?有权力定义规则的人生活已经很舒服了,为什么要颠覆自己呢?对于大多数传统车企,比较现实的策略是渐进式变革。
软件开发模式仍然苦难重重:
· 软件层次划分不够,专注于研发关键技术的组织规模
· 软件技术的使用偏保守
· 基础软件提供功能偏向通用化,旨在针对首要关键技术的公共模块
· 生态较封闭,大量软件工作花费在不同软硬件组合的适应上
短期阵痛:
1. 软件定义汽车,选择技术路线很关键,就是选择合作伙伴。跟谁合作?做什么?如何分工?
2. 我们既不能什么都做,也不能什么都不做;
3. 你带的合作伙伴靠不靠得住,不要搞了两三年之后,等你量产的时候,它倒下了;
4. 不要盲目拒绝和否认新的技术和产品,没有完美的技术;
5. 时间、范围、能力合作伙伴的协同关系。
软件定义汽车中长期挑战:
1. 公司战略与管理层知识结构;
2. 企业文化;
3. 组织架构与技能匹配;
4. 开发、生产、售后、维护, 全生命周期流程需要重新定义;
5. 重塑供应链及运行模式。
07 结语
-
汽车测试网V课堂
-
微信公众号
-
汽车测试网手机站
编辑推荐
最新资讯
-
“源”察秋毫--多次循环双脉冲测试应用助力
2024-11-18 11:20
-
华东智能网联汽车试验场正式启动运营
2024-11-18 10:37
-
捷豹路虎基于R290应用于汽车热泵系统的性能
2024-11-18 09:21
-
软件更新:UN R156拟强制实施RxSWIN
2024-11-18 09:20
-
新能源汽车换挡方式的进化
2024-11-18 09:19